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