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

[Ove K. Pettersen]

Den 05.02.2012 22:22, skrev Whit Blauvelt:
> Not sure if you're asking your questions precisely enough. The clues may be
> in your inclusions, but I'm not going to read all that to figure it out so
> I'll ask directly:
>
>> Short description of my test
>> ----------------------------
>> * 4 replicas on single machine
>> * glusterfs mounted locally
>> * Create file on glusterfs-mounted directory: date>data.txt
> Did you write it through a gluster (or nfs) mount of the gluster file
> system, or sneak around behind it with a direct local mount of the
> partition?
This was of course done to the glusterfs-type mounted filesystem.
So that the glusterfs-client can save it out on all the bricks.
>
>> * 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.

>> * Trigger a self-heal with: stat data.txt
> Again, stat'ing it on a gluster/nfs mount, or a local mount?
The stat was done to the glusterfs-type mount. As I understand it, the 
healing is done by the glusterfs-client.
>> =>  Modified file on the brick is still different from the three
>> other bricks.
> Again ... well you know.
>
>> Q1: Is the modified file supposed to get corrected in my case?
>>
>> Q2: Is my test-case invalid for what gluster is supposed to handle?
> If you're writing to files through mounts which gluster isn't handling,
> you'll get inconsistent stuff. Eventually gluster should catch up. But by
> design you should do everything through gluster. (An exception may be if you
> want a faster local file read ... anything that writes or touches the file
> should be through gluster in any case.)
I know everything has to be done through an glusterfs-mounted filesystem 
(lets keep the nfs-mounting away).

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.

I have tested if files are missing on a brick => It is copied from 
another replica when healed.

There are however failures that fall in between the 100% working brick 
and the one which is 100% disappeared.
These cases interests me.

> Best,
> Whit
>