+++ This bug was initially created as a clone of Bug #1452083 +++ Description of problem: Version-Release number of selected component (if applicable): mainline How reproducible: if cache and hash subvolme of hardlink is different Steps to Reproduce: Run link/00.t test from posix testsuite(pjdtest suite) on nfs clients using ganesha Steps executed in script * create a file "abc" using root * create hardlink "link" for "abc" using a non root user, it fails with EACESS * delete "abc" * create directory "abc" using root * again try to create hadrlink "link" for "abc" using non root user, fails with ESTALE Actual results: Fails with ESTALE Expected results: Fail with EACESS Additional info: This is a similar issue fixed for rename in https://review.gluster.org/#/c/16016/ For hardlinks, if cached and hashed subvolumes are different, then it will first create linkto file in hashed using root permission, but actually hardlink creation fails with EACESS and stale linkto file is never removed. All the followup hardlink calls with file name will result ESTALE due to that linkto file. In the code mknod call for the linkto('T')[as part of dht_link] fails with EEXIST and following lookup results in ESTALE Thanks Susant for the help in RCAing above issue
REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#1) for review on master by jiffin tony Thottan (jthottan)
REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#2) for review on master by jiffin tony Thottan (jthottan)
REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#3) for review on master by jiffin tony Thottan (jthottan)
REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#4) for review on master by jiffin tony Thottan (jthottan)
REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#5) for review on master by jiffin tony Thottan (jthottan)
REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#6) for review on master by jiffin tony Thottan (jthottan)
REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#7) for review on master by jiffin tony Thottan (jthottan)
COMMIT: https://review.gluster.org/17331 committed in master by Raghavendra G (rgowdapp) ------ commit 237648780336d41cd6d820c337b38dd13f4d9e72 Author: Jiffin Tony Thottan <jthottan> Date: Thu May 18 11:22:16 2017 +0530 dht/hardlink : Remove stale linkto file incase of failure This is a similar issue fixed for rename in https://review.gluster.org/#/c/16016/ For hardlinks, if cached and hashed subvolumes are different, then it will first create linkto file in hashed using root permission, but actually hardlink creation fails with EACESS and stale linkto file is never removed.All the followup hardlink calls with file name will result ESTALE because linktofile creation fails with EEXIST and follow up lookup on linkto file returns gfid-mismatching(old linkto file) and finally fails with ESTALE Steps to produce : (From link/00.t test from posix-testsuite) Steps executed in script * create a file "abc" using root * change the ownership of file to a non root user * create hardlink "link" for "abc" using a non root user, it fails with EACESS * delete "abc" * create directory "abc" using root * again try to create hadrlink "link" for "abc" using non root user, fails with ESTALE Also tried to fix other bugs in dht_linkfile_create_cbk() and posix_lookup. Thanks Susant for the help in debugging the issue and suggestion for this patch. Change-Id: I7a5a1899d3fd1fdb13578b37f9d52a084492e35d BUG: 1452084 Signed-off-by: Jiffin Tony Thottan <jthottan> Reviewed-on: https://review.gluster.org/17331 Smoke: Gluster Build System <jenkins.org> Reviewed-by: N Balachandran <nbalacha> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Raghavendra G <rgowdapp>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.12.0, please open a new bug report. glusterfs-3.12.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://lists.gluster.org/pipermail/announce/2017-September/000082.html [2] https://www.gluster.org/pipermail/gluster-users/