[Gluster-users] Would difference in size (and content) of a file on replicated bricks be healed?
Pranith Kumar K
pranithk at gluster.com
Mon Feb 6 14:58:55 UTC 2012
On 02/06/2012 04:46 AM, Whit Blauvelt wrote:
> On Sun, Feb 05, 2012 at 10:46:53PM +0100, Ove K. Pettersen wrote:
>>>> * Append to file on one of the bricks: hostname>>data.txt
>>> Again, through a gluster/nfs mount, or a local mount?
>> This was done directly to a brick (local mount) to try to simulate
>> some disk-problems.
>> Appending to the file would keep the extended attributes. Gluster
>> should still handle the file
>> as its own.
> This is an open question. I don't know the answer. But I wonder. Is there
> any real-world problem that would result in the same pattern? That is,
> you've changed a file outside of gluster, not in any way that results in an
> actually-corrupt file, but instead a file that in terms of the way you wrote
> to it is still totally good. So how often is some random disk corruption
> going to happen that results in a file which is in fact fully legitimate?
>> But my goal is to simulate something going wrong on a disk.
>> That is not predicted events done through a glusterfs-mounted
>> filesystem but rather happens directly to a brick.
> A better simulation might be through using a hex editor to change a few
> bytes in the file, without touching attributes or inodes at all. Haven't
> tried it. Don't know whether gluster would spot the corruption and fix it or
> not. But that would be a lot closer to bits flipping from hardware errors.
> Gluster-users mailing list
> Gluster-users at gluster.org
Modifying the data directly on the brick in a replica pair(Brick
A, Brick B) is a bad thing because it will not be possible to decide in
which direction to heal the contents of the file B -> A or A -> B. If
the file is modified from the mount point then the glusterfs client
marks the extended attributes so that it knows in which direction to
heal the files.
More information about the Gluster-users