On 02/17/2014 03:06 PM, Pranith Kumar Karampuri wrote:
----- Original Message -----
From: "Chetan Risbud" <cris...@redhat.com>
To: "Pranith Kumar Karampuri" <pkara...@redhat.com>
Cc: "Jiffin Thottan" <jthot...@redhat.com>, gluster-devel@nongnu.org
Sent: Monday, February 17, 2014 3:00:07 PM
Subject: Re: [Gluster-devel] Trash translator for GlusterFS
----- Original Message -----
From: "Pranith Kumar Karampuri" <pkara...@redhat.com>
To: "Jiffin Thottan" <jthot...@redhat.com>
Cc: gluster-devel@nongnu.org
Sent: Monday, February 17, 2014 2:51:44 PM
Subject: Re: [Gluster-devel] Trash translator for GlusterFS
----- Original Message -----
From: "Jiffin Thottan" <jthot...@redhat.com>
To: "Niels de Vos" <nde...@redhat.com>
Cc: gluster-devel@nongnu.org
Sent: Monday, February 17, 2014 2:27:29 PM
Subject: Re: [Gluster-devel] Trash translator for GlusterFS
Hi Niels,
The deleted files are moved to trash directory by appending timestamp to
file
name.So there is no chance of name collisions.The trash directory will be
present in every brick.
In the given scenario,both README files are shown separately in trash
directory with different timestamps.
What if two files are created, deleted with in a second? What if the file is
already 254 characters? (maximum file name length is 255 I think)
A HASH of the 'metadata' of the original file appended to the name of
the file to be deleted would help differentiate ?
It still does not help in file-names of length 254.
Another possibility is to always truncate the file name to NAME_MAX
minus the size required for timestamp. The real file name could be
stored as an extended attribute of the file in trash.
Yet another possibility would be to have the files stored as gfid with
the timestamp appended. A separate external mapping mechanism (files,
sqlite, mongo) could provide gfid ==> file name translations.
-Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
