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