Please find my comments inline.
On 9/22/18 8:56 AM, Raghavendra Gowdappa wrote:
On Fri, Sep 21, 2018 at 11:25 PM Raghavendra Gowdappa
<rgowdapp@xxxxxxxxxx <mailto:rgowdapp@xxxxxxxxxx>> wrote:
Hi all,
We've a feature performance.parallel-readdir [1] that is known to
improve performance of readdir operations [2][3][4]. 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 [4].
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.
IMHO, this is a must fix to enable this option by default.
* fixes to maintain stat-consistency in dentries pre-fetched have
not made into downstream yet (though merged upstream [5]).
* 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 or purged.
As you had explained, since this affects cache-consistency, this as well
needs to be addressed.
* dht linkto-files should store relative positions of subvolumes
instead of absolute subvolume name, so that changes to immediate
child won't render them stale.
FWIU from your explanation, this may affect performance for a brief
moment when the option is turned on but as such doesn't result in
incorrect results. So considering that these options are usually
configured at the beginning of the volume configuration and not toggled
often, this may not be blocker.
* Features parallel-readdir depends on to be working should be
enabled automatically even though they were off earlier when
parallel-readdir is enabled [6].
Since readdir-ahead is one such option which was not turned on (by
default) till now and most of the above mentioned issues are with
readdir-ahead, will it be helpful if we enable only readdir-ahead for
few releases, get enough testing done and then consider parallel-readdir?
Thanks,
Soumya
I've listed important known issues above. But we can discuss which
are the blockers for making this feature as a default.
Thoughts?
[1] http://review.gluster.org/#/c/16090/
[2]
https://events.static.linuxfound.org/sites/events/files/slides/Gluster_DirPerf_Vault2017_0.pdf
(sections on small directory)
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1628807#c35
<https://bugzilla.redhat.com/show_bug.cgi?id=1628807#c34>
[4] https://www.spinics.net/lists/gluster-users/msg34956.html
[5] http://review.gluster.org/#/c/glusterfs/+/20639/
[6] https://bugzilla.redhat.com/show_bug.cgi?id=1631406
regards,
Raghavendra
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
