|author||Anoop C S <firstname.lastname@example.org>||2016-02-08 15:52:24 +0530|
|committer||Vijay Bellur <email@example.com>||2016-03-18 18:27:33 -0700|
feature doc: Trash translator improvements
Change-Id: I74a4cae711f91cb76cea1de29ff0d66d79471aec Signed-off-by: Anoop C S <firstname.lastname@example.org> Reviewed-on: http://review.gluster.org/13399 Reviewed-by: jiffin tony Thottan <email@example.com> Reviewed-by: Vijay Bellur <firstname.lastname@example.org> Tested-by: Vijay Bellur <email@example.com>
Diffstat (limited to 'accepted')
1 files changed, 121 insertions, 0 deletions
diff --git a/accepted/Trash-Improvements.md b/accepted/Trash-Improvements.md
new file mode 100644
@@ -0,0 +1,121 @@
+Trash feature improvements
+Improvize and stabilize the current implementational limitations inside trash
+translator to provide better usability of trashed files inside trash directory.
+Anoop C S <firstname.lastname@example.org>
+Jiffin Tony Thottan <email@example.com>
+As per the current implementation, trash translator resides on glusterfs server
+stack just above the posix translator. With volume start default trash directory
+named '.trashcan' is created under root of the volume and is visible from any
+type of mount. When trash feature is enabled for a volume, an unlink/truncate
+operation will result in renaming the file to trash directory with an appended
+time stamp in the file name. Moreover, exact directory hierarchy (w.r.t root of
+the volume) is maintained inside .trashcan whenever a file is deleted/truncated
+from a directory inside volume. See (1) for more details regarding this feature.
+And here are the outstanding issues:
+* Since renaming occurs at the server side, client-side is unaware of trash
+ doing rename or create operations.
+* As a result files/directories may not be visible from mount point.
+* Files/Directories created from from trash translator will not have gfid
+ associated with it until lookup is performed.
+Related Feature Requests and Bugs
+RFE : Create trash directory only when its is enabled
+RFE : Flat hierarchy for files inside trash directory
+RFE : trash helper translator at client-side
+RFE : Restore operation for files under trash directory
+Instead of creating the whole directory hierarchy under trash and maintaining
+its consistency over every bricks per volume we will now rename the file and
+place it directly under trash directory. As before timestamp will be appended
+to the filename. After rename the original directory hierarchy w.r.t root of
+the volume shall be stored as an extended attribute for the trashed file. As
+part of these changes following enhancements are also being considered:
+* As of now a volume start will automatically trigger the creation of trash
+ directory on each brick. This creation can be made as part of the volume set
+ operation that is used to enable trash translator for a volume.
+* Instead of preventing operations like unlink, rename etc on trash directory
+ all the time, we can enable this prevention only when trash is enabled for
+ the volume.
+* Introduce a new trash helper translator on client side to resolve gfid
+ mismatch issues with files being moved to trash directory during truncation of
+ files. This helper translator will reside on client stack as long as trash is
+ enabled for a volume.
+* With the help of an explicit setfattr call from mount, restoration of trashed
+ files can be made possible. During restoration if original path does not
+ exists it will be created with default permissions.
+Benefit to GlusterFS
+Restoration and improved consistency of trashed files inside a glusterfs volume.
+#### Nature of proposed change
+* Modification to existing trash translator code
+* New trash helper translator to be loaded on client side when trash is enabled.
+#### Implications on manageability
+#### Implications on presentation layer
+#### Implications on persistence layer
+#### Implications on 'GlusterFS' backend
+#### Modification to GlusterFS metadata
+New extended attribute named 'trusted.originpath' will be set for every trashed
+file inside trash directory which will store the previous path for the file
+before unlink or truncate operations.
+#### Implications on 'glusterd'
+How To Test
+To restore files from trash directory, users will have do a setfattr with a
+special key (to be decided) on the required file.
+Comments and Discussion