[Gluster-users] Would difference in size (and content) of a file on replicated bricks be healed?

[Pranith Kumar K]

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.
>
> Whit
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
hi,
      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.

Pranith