[Gluster-devel] Suggestions on implementing trash translator

[Xavier Hernandez]

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

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 ?

Xavi