Ravi, We should not mix up data and entry operation domains, if a file is in data split brain that should not stop a user from rename/link/unlink operations on the file. Regarding your concern about complications while healing - we should change our "manual fixing" instructions to: - go to backend, access through gfid path or normal path - rmxattr the afr changelogs - truncate the file to 0 bytes (like "> filename") Accessing the path through gfid and truncating to 0 bytes addresses your concerns about hardlinks/renames. Avati On Wed, Nov 13, 2013 at 3:01 AM, Ravishankar N <ravishankar at redhat.com>wrote: > Hi, > > Currenly in glusterfs, when there is a data splt-brain (only) on a file, > we disallow the following operations from the mount-point by returning EIO > to the application: > - Writes to the file (truncate, dd, echo, cp etc) > - Reads to the file (cat) > - Reading extended attributes (getfattr) [1] > > However we do permit the following operations: > -creating hardlinks > -creating symlinks > -mv > -setattr > -chmod > -chown > --touch > -ls > -stat > > While it makes sense to allow `ls` and `stat`, is it okay to add checks > in the FOPS to disallow the other operations? Allowing creation of links > and changing file attributes only seems to complicate things before the > admin can go to the backend bricks and resolve the splitbrain (by deleteing > all but the healthy copy of the file including hardlinks). More so if the > file is renamed before addressing the split-brain. > Please share your thoughs. > > Thanks, > Ravi > > [1] http://review.gluster.org/#/c/5988/ > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131115/6b766b21/attachment.html>
