[Gluster-devel] Implementing Flat Hierarchy for trashed files

[Anoop C S]

On Mon, 2015-08-17 at 23:15 +0530, Soumya Koduri wrote:
> This approach sounds good. Few inputs/queries inline.
> 
> 
> On 08/17/2015 06:20 PM, Anoop C S wrote:
> > Hi all,
> > 
> > As we move forward, in order to fix the limitations with current
> > trash
> > translator we are planning to replace the existing criteria for
> > trashed
> > files inside trash directory with a general flat hierarchy as
> > described
> > in the following sections. Please have your thoughts on following
> > design considerations.
> > 
> > Current implementation
> > ======================
> > * Trash translator resides on glusterfs server stack just above
> > posix.
> > * Trash directory (.trashcan) is created during volume start and is
> >    visible under root of the volume.
> > * Each trashed file is moved (renamed) to trash directory with an
> >    appended time stamp in the file name.
> > * Exact directory hierarchy (w.r.t the root of volume) is
> > maintained
> >    inside trash directory whenever a file is deleted/truncated from
> > a
> >    directory
> > 
> > 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.
> > 
> > Proposed Flat hierarchy
> > =======================
> > * Instead of creating the whole directory under trash, we will
> > rename
> >    the file and place it directly under trash directory (of course
> > with
> >    appended time stamp).
> > * Directory hierarchy can be stored via either of the following two
> >    approaches:
> > 	(a) File name will contain the whole path with time stamp
> > 	    appended
> > 	(b) Store whole hierarchy as an xattr
> > 
> IMO, (b) sounds better compared to (a) as storing entire hierarchical
> path as the file name may end up reaching file_name max length limit 
> sooner. Also users may wish to look at the file names with the
> original 
> names for easy identification in the .trash directory.
> 
> > Other enhancements
> > ==================
> > * Create the trash directory only
> > when trash xlator is enabled.
> 
> Can the trash xlator be disabled once its enabled? If yes, will the 
> files be still visible from the mount point?
> 

Trash translator can be disabled and trash directory will be still
visible from the mount point with its contents. 

> > * Operations such as unlink, rename etc
> > will be prevented on trash
> >    directory only when trash xlator is
> > enabled.
> > * A new trash helper translator on client side(loaded only when
> > trash
> >    is enabled) to resolve split brain issues with truncation of
> > files.
> Doesn't AFR/EC already take care of this? Could you please provide
> more 
> details on this issue.
> 

With trash translator enabled, truncate is performed in 2 steps:
(1) Read from the original file and create an exact copy under trash
directory. This create call from trash translator will miss gfid for
that file under trash directory.
(2) Truncate the original file.

> 
> Thanks,
> Soumya
> 
> > * Restore files from trash with the help of an explicit setfattr
> > call.
> > 
> > Thanks & Regards,
> > -Anoop C S
> > -Jiffin Tony Thottan
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> >