[Gluster-devel] Fwd: Impact of direct-io-mode on mail-box work load
Amar Tumballi
atumball at redhat.com
Wed Apr 5 01:57:41 UTC 2017
On Fri, Mar 31, 2017 at 4:03 PM, Bipin Kunal <bkunal at redhat.com> wrote:
> Hello,
>
> Can someone explain me the importance of "direct-io-mode"?
> What I understand is enabling "direct-io-mode" will use FUSE cache and
> bypass kernel/page cache.
>
> Will it be beneficial to enable "direct-io-mode" or it will have adverse
> effect when there is very small files workload such as dovecot and other
> mail boxes.
> As use case here is of mail boxes, it will be write once and mostly read
> once.
>
>
Mailbox workload involves mainly 2 major posix semantics.
1. Locking
2. Dependency on rename().
And later the challenge of small files.
In distributed systems both 1 and 2 mentioned above are harder problem to
achieve without performance compromise (ref: CAP). This makes it harder
problem to solve for GlusterFS usecase.
Well, I am hopeful of already proposed gfid based hashing in DHT-next
algorithm to solve some of it, along with few locking enhancements people
are planning by GlusterFS 4.0 timeframe, we can revisit this usecase.
For the historic nostalgia, I went through the logs to figure out when did
anyone first tried mailbox related workload with glusterfs, and seems 2008
is the answer [1] :-)
Regards,
Amar
[1] - http://savannah.nongnu.org/bugs/?24551
> --
> Thanks,
>
> Bipin Kunal
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
--
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170405/90bd4ec1/attachment.html>
More information about the Gluster-devel
mailing list