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