Re: Suggestions on implementing trash translator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux