[Bugs] [Bug 1341429] New: successful mkdir from "bad" subvolume should be ignored while propagating result to higher layer

bugzilla at redhat.com bugzilla at redhat.com
Wed Jun 1 04:31:28 UTC 2016


https://bugzilla.redhat.com/show_bug.cgi?id=1341429

            Bug ID: 1341429
           Summary: successful mkdir from "bad" subvolume should be
                    ignored while propagating result to higher layer
           Product: GlusterFS
           Version: mainline
         Component: replicate
          Assignee: bugs at gluster.org
          Reporter: rgowdapp at redhat.com
                CC: bugs at gluster.org



Description of problem:

For Preop checks like [1], dentry operations like mkdir etc would rely on
xattrs on parent (like dht layout). However, a "bad" subvolume of afr cannot
make correct decision during preop check as the xattrs are not guaranteed to be
correct. Imagine the following scenario:
a. mkdir succeeds on non-readable subvolume
b. fails on readable subvolume (may be because of layout xattrs didn't match).

afr here would report mkdir as success to parent xlators (here dht). However,
since non-readable subvolume is not guaranteed to have correct xattrs, mkdir
shouldn't have succeeded. Worse still, if mkdir on readable subvolume had
failed because preop check failed (client in memory layout xattrs and layout
xattrs persisted on disk didn't match), we would be ignoring a genuine failure
and instead transforming it as a success.

dht is planning to introduce pre-operation checks on all dentry and lock
(posix-locks, inodelk, entrylk) operations. So, without some sort of support
from lower layers on xattr consistency (as these preops primarily rely on
xattrs) it is impossible for a correct implementation.

[1] http://review.gluster.org/13885


Version-Release number of selected component (if applicable):
mainline, 3.7.11, 3.8

How reproducible:
bug was filed as a result of design discussion.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list