Re: [Gluster-devel] Suggestions on implementing trash translator
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@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Suggestions on implementing trash translator
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 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Suggestions on implementing trash translator
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@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Suggestions on implementing trash translator
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@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel