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
