[Gluster-devel] Implementing Flat Hierarchy for trashed files

Soumya Koduri skoduri at redhat.com
Mon Aug 17 17:45:39 UTC 2015


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?

> * 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.


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
>


More information about the Gluster-devel mailing list