[Gluster-devel] On making performance.parallel-readdir as a default option
rgowdapp at redhat.com
Sat Sep 22 03:25:06 UTC 2018
We've a feature performance.parallel-readdir  that is known to improve
performance of readdir operations . The option is especially
useful when distribute scale is relatively large (>10) and is known to
improve performance of readdir operations even on smaller scale of
distribute count 1 .
However, this option is not enabled by default. I am here proposing to make
this as a default feature.
But, there are some important things to be addressed in readdir-ahead
(which is core part of parallel-readdir), before we can do so:
To summarize issues with readdir-ahead:
* There seems to be one prominent problem of missing dentries with
parallel-readdir. There was one problem discussed on tech-list just
yesterday. I've heard about this recurrently earlier too. Not sure whether
this is the problem of missing unlink/rmdir/create etc fops (see below) in
readdir-ahead. ATM, no RCA.
* fixes to maintain stat-consistency in dentries pre-fetched have not made
into downstream yet (though merged upstream ).
* readdir-ahead doesn't implement directory modification fops like
rmdir/create/symlink/link/unlink/rename. This means cache won't be updated
wiith newer content, even on single mount till its consumed by application
* dht linkto-files should store relative positions of subvolumes instead of
absolute subvolume name, so that changes to immediate child won't render
* Features parallel-readdir depends on to be working should be enabled
automatically even though they were off earlier when parallel-readdir is
I've listed important known issues above. But we can discuss which are the
blockers for making this feature as a default.
(sections on small directory)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel