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