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

[Whit Blauvelt]

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