[Gluster-devel] Suggestions on implementing trash translator

[Xavier Hernandez]

On Tuesday 22 July 2014 22:02:53 Anoop C S wrote:
> > 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.

It can be inside .glusterfs if posix offsers some help and accesses to it are 
intercepted and translated by trash xlator. 

rmdir can only be intercepted if trash xlator is enabled. If it's disabled, 
users will be able to delete the directory or even copy things inside because 
posix will return it as any other normal directory. Of course another option 
would be to move all this logic to posix, but I'm not sure if this won't mix 
both xlators too much.

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

For example, what will happen if a file being healed (missing in some bricks) 
is deleted ? how that file will be recovered ?

As I see it, afr will think that the file has been deleted, so it won't try to 
heal it, however the file won't have been deleted and can reappear in the 
future. When that happens, the file will be recovered from some bricks, but 
not from others. How will afr be aware of the recovered file and its state ?

I think that having trash below dht, afr and ec make it necessary to modify 
these xlators to handle some special cases. But I might be wrong.

Xavi