[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