Re: Implementing Flat Hierarchy for trashed files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux