rgowdapp at redhat.com
Tue Feb 23 02:03:56 UTC 2016
----- Original Message -----
> From: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
> To: "Keiviw" <keiviw at 163.com>
> Cc: gluster-devel at gluster.org
> Sent: Tuesday, February 23, 2016 7:30:51 AM
> Subject: Re: [Gluster-devel] Readdir-ahead
> ----- Original Message -----
> > From: "Keiviw" <keiviw at 163.com>
> > To: gluster-devel at gluster.org
> > Sent: Tuesday, February 23, 2016 6:20:28 AM
> > Subject: [Gluster-devel] Readdir-ahead
> > I have two questions about the performance,readdir-ahead.
> > 1. In the code,the request max_size is 131072,128K. If i change the
> > max_size
> > to a larger size, what will happen?
> readdir-ahead winds down readdir calls with a buffer of size "max_size". If
> you increase the size, each readdir (including those "preload" requests
> which are not issued by application)
Correction. Only preload requests are issued with buffers of size "max_size". If readdir-ahead is bypassed (for various reasons), there is no change in size of buffer.
> will be done with a bigger buffer to
> fetch dentries.
> > 2. As what i have said in question 1, for a larger buffer, if the second
> > readdir arrives, the denty will return from the buffer or from the server?
> Only if a preload (a readdir request not initiated by application, but
> instead triggered by readdir-ahead in an attempt to pre-emptively fill the
> read-ahead buffer) is in progress, a readdir from application waits for its
> completion. For all other cases, readdir-ahead is bypassed. Also note that
> readdir-ahead is "per-fd" based cache. So, barring cases like duping an fd
> (including fork() ), one shouldn't get parallel readdir requests on a single
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
More information about the Gluster-devel