[Gluster-devel] Suggestions on implementing trash translator

[Jiffin Tony Thottan]

On 22/07/14 22:25, Xavier Hernandez wrote:
> 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.


The authority of trash directory is given to posix translator.So all the 
fops effecting the trash directory should be  handled by posix translator


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

In current scenario , files that are being moved to trash directory as 
part of heal operation will be replicated in corresponding bricks too.

> 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

Jiffin

> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel