[Gluster-devel] Suggestions on implementing trash translator

[Anoop C S]

On 07/22/2014 06:58 PM, Xavier Hernandez wrote:
> On Tuesday 22 July 2014 07:33:44 Jiffin Thottan wrote:
>> Hi,
>>
>> There are some issues we are dealing with trash translator(see attachment
>> for design doc).In our implementation, we create trash directory using
>> trash translator.Thus trash directories on different bricks will have
>> different gfids.A gfid conflict will arise.
>>
>> * To deal with gfid issue we tried to create trash directory using posix
>> translator and set fixed gfid for trash directory.And gfid conflict was
>> solved.Is this solution feasible?
> I think that a global fixed gfid is is the right solution here.
>
>> * Trash directory is a configurable option by trash translator from cli.So
>> when we perform volume set for changing the trash directory,it will be
>> available in trash translator's dictionary.It is not passed to posix
>> translator(every translator will have different dictionaries for them).The
>> only way is to make configurable option as part of posix translator.Is this
>> a right way of implementation?
> I think that mixing options from one xlator into another is not a good idea.
> Specially if one xlator can be disabled, because the other will have to know
> in which state is the former to react differently (for example not showing the
> trash directory if trash xlator is disabled).
>
>> * When a trash directory is reconfigured from cli  , whether we need to
>> perform a rename operation from old trash directory to new one or just
>> create new trash directory?
> A rename would be better (all trash contents will be kept) than creating a new
> directory (and moving all data ?), however if the option reconfiguration is
> done while the volume is stopped, such rename won't be possible. And even
> worst, when the volume starts you won't know if there has been any change in
> the directory name, so you would need to validate some things on each start to
> avoid duplicate trash directories.
>
> Maybe it would be better that the directory name were fixed from the posix
> point of view, but the trash xlator return the configured name to upper
> xlators on readdir(p) for example.
>
>>
>> To summarize , we trying to make posix translator as the owner of trash
>> directory and trash translator will intercept fops like unlink,truncate .
>> What are your suggestions for it?
> I see some other issues to this approach.
>
> 1. If the directory is physically created inside the normal namespace of
> posix, it will be visible even if you disable the xlator. In this case all
> users will have uncontrolled access to the trash directory. It should
> "disappear" when trash xlator is disabled. A possible solution to this would
> be to have this directory inside .glusterfs (some support from posix would be
> needed).
The trash directory should be visible from mount point. So it cannot be 
inside .glusterfs.
rmdir and mkdir calls are not permitted over trash directory.
> 2. I'm not sure how this local management on each brick will affect higher
> level xlators like dht, afr or ec, or complex functions like self-heal.
> Couldn't this be a problem ?
calls from dht, self-heal etc will be treated by trash translator 
similar to other fops. For example, truncate call during re-balance 
operation is intercepted by trash translator.
> Xavi
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel