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
