From 6945ccdc06802be27db3c92ab33aee0c4a20f9db Mon Sep 17 00:00:00 2001 From: Anoop C S Date: Mon, 8 Feb 2016 15:52:24 +0530 Subject: feature doc: Trash translator improvements Change-Id: I74a4cae711f91cb76cea1de29ff0d66d79471aec Signed-off-by: Anoop C S Reviewed-on: http://review.gluster.org/13399 Reviewed-by: jiffin tony Thottan Reviewed-by: Vijay Bellur Tested-by: Vijay Bellur --- accepted/Trash-Improvements.md | 121 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 accepted/Trash-Improvements.md (limited to 'accepted/Trash-Improvements.md') diff --git a/accepted/Trash-Improvements.md b/accepted/Trash-Improvements.md new file mode 100644 index 0000000..19ce600 --- /dev/null +++ b/accepted/Trash-Improvements.md @@ -0,0 +1,121 @@ +Feature +------- +Trash feature improvements + +Summary +------- +Improvize and stabilize the current implementational limitations inside trash +translator to provide better usability of trashed files inside trash directory. + +Owners +------ +Anoop C S +Jiffin Tony Thottan + +Current status +-------------- +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. + +(1) [http://www.gluster.org/community/documentation/index.php/Features/Trash] + +Related Feature Requests and Bugs +--------------------------------- +[https://bugzilla.redhat.com/show_bug.cgi?id=1264849] +RFE : Create trash directory only when its is enabled + +[https://bugzilla.redhat.com/show_bug.cgi?id=1264847] +RFE : Flat hierarchy for files inside trash directory + +[https://bugzilla.redhat.com/show_bug.cgi?id=1264853] +RFE : trash helper translator at client-side + +[https://bugzilla.redhat.com/show_bug.cgi?id=1264857] +RFE : Restore operation for files under trash directory + +Detailed Description +-------------------- +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. + +Scope +----- + +#### 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 +----------- + +User Experience +--------------- +To restore files from trash directory, users will have do a setfattr with a +special key (to be decided) on the required file. + +Dependencies +------------ + +Documentation +------------- + +Status +------ +In development. +[http://review.gluster.org/#/q/topic:bug-1264849+OR+topic:bug-1264847+OR+topic:bug-1264853+OR+topic:bug-1264857] + +Comments and Discussion +----------------------- -- cgit