Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distritbute: [RFE] More robust transactions during directory namespace operations. #191

Closed
kotreshhr opened this issue Apr 26, 2017 · 5 comments
Assignees

Comments

@kotreshhr
Copy link
Contributor

Main Issue:
#116

Design Doc:
https://review.gluster.org/16876

This issue tracks the effort introducing atomicity in operations on directory namespace like mkdir, rmdir,
renamedir and directory creation phase of lookup heal.

Patch Details:
https://review.gluster.org/#/c/15472/
Relevant Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1443373

mscherer pushed a commit that referenced this issue Apr 26, 2017
Design doc: https://review.gluster.org/16876

Directory creation is now synchronized with blocking inodelk of the
parent on the hashed subvolume followed by the entrylk on the hashed
subvolume between dht_mkdir, dht_rmdir, dht_rename_dir and lookup
selfheal mkdir.

To maintain internal consistency of directories across all subvols of
dht, we need locks. Specifically we are interested in:

 1. Consistency of layout of a directory. Only one writer should modify
    the layout at a time. A writer (layout setting during directory heal
    as part of lookup) shouldn't modify the layout while there are
    readers (all other fops like create, mkdir etc., which consume
    layout) and readers shouldn't read the layout while a writer is in
    progress. Readers can read the layout simultaneously. Writer takes
    a WRITE inodelk on the directory (whose layout is being modified)
    across ALL subvols. Reader takes a READ inodelk on the directory
    (whose layout is being read) on ANY subvol.

 2. Consistency of directory namespace across subvols. The path and
    associated gfid should be same on all subvols. A gfid should not be
    associated with more than one path on any subvol. All fops that can
    change directory names (mkdir, rmdir, renamedir, directory creation
    phase in lookup-heal) takes an entrylk on hashed subvol of the
    directory.

 NOTE1: In point 2 above, since dht takes entrylk on hashed subvol of a
        directory, the transaction itself is a consumer of layout on
        parent directory. So, the transaction is a reader of parent
        layout and does an inodelk on parent directory just like any
        other layout reader. So a mkdir (dir/subdir) would:

     > Acquire a READ inodelk on "dir" on any subvol.
     > Acquire an entrylk (dir, "subdir") on hashed subvol of "subdir".
     > creates directory on hashed subvol and possibly on non-hashed subvols.
     > UNLOCK (entrylk)
     > UNLOCK (inodelk)

 NOTE2: mkdir fop while setting the layout of the directory being created
        is considered as a reader, but NOT a writer. The reason is for
        a fop which can consume the layout of a directory to come either
        of the following conditions has to be true:

     > mkdir syscall from application has to complete. In this case no
       need of synchronization.
     > A lookup issued on the directory racing with mkdir has to complete.
       Since layout setting by a lookup is considered as a writer, only
       one of either mkdir or lookup will set the layout.

Code re-organization:
   All the lock related routines are moved to "dht-lock.c" file.
   New wrapper function is introduced to take blocking inodelk
   followed by entrylk 'dht_protect_namespace'

Updates #191
Change-Id: I01569094dfbe1852de6f586475be79c1ba965a31
Signed-off-by: Kotresh HR <khiremat@redhat.com>
BUG: 1443373
Reviewed-on: https://review.gluster.org/15472
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
Reviewed-by: Raghavendra G <rgowdapp@redhat.com>
Smoke: Gluster Build System <jenkins@build.gluster.org>
@ShyamsundarR ShyamsundarR added this to the Release 3.11 (STM) milestone Apr 26, 2017
@ShyamsundarR ShyamsundarR added this to Release 3.11 in Releases Apr 26, 2017
mscherer pushed a commit that referenced this issue Apr 27, 2017
Change-Id: If69d67ce5dffe966fbc1e4ad834ca110e1e0b745
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Updates: #191
Reviewed-on: https://review.gluster.org/16876
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
Smoke: Gluster Build System <jenkins@build.gluster.org>
@amarts
Copy link
Member

amarts commented May 24, 2017

Closed with 4076b73

@ShyamsundarR
Copy link
Contributor

Attention @kotreshhr

We need the release notes for 3.11 updates with details about this feature.

@ShyamsundarR ShyamsundarR reopened this May 25, 2017
@gluster-ant
Copy link
Collaborator

A patch https://review.gluster.org/17415 has been posted that references this issue.
Commit message: doc: Update release notes for 3.11.0 release

2 similar comments
@gluster-ant
Copy link
Collaborator

A patch https://review.gluster.org/17415 has been posted that references this issue.
Commit message: doc: Update release notes for 3.11.0 release

@gluster-ant
Copy link
Collaborator

A patch https://review.gluster.org/17415 has been posted that references this issue.
Commit message: doc: Update release notes for 3.11.0 release

mscherer pushed a commit that referenced this issue May 30, 2017
Edits, md formatting corrections and added missing release notes
for 3 features.

Fixes #191
Fixes #188
Fixes #176

Change-Id: I8502391bfcef8a65fa7fd802aacedfe3c595d04b
Signed-off-by: Shyam <srangana@redhat.com>
Reviewed-on: https://review.gluster.org/17415
CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
Smoke: Gluster Build System <jenkins@build.gluster.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants