[Gluster-devel] [Gluster-users] Fencing FOPs on data-split-brained files
avati at gluster.org
Fri Nov 15 20:12:56 UTC 2013
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.
On Wed, Nov 13, 2013 at 3:01 AM, Ravishankar N <ravishankar at redhat.com>wrote:
> 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) 
> However we do permit the following operations:
> -creating hardlinks
> -creating symlinks
> 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.
>  http://review.gluster.org/#/c/5988/
> Gluster-users mailing list
> Gluster-users at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel