[Gluster-devel] afr logic
kbenson at a-1networks.com
Wed Oct 17 15:47:22 UTC 2007
Hans Einar Gautun wrote:
> Hi, and thanks for all good and tested tricks and facts;)
> tir, 16,.10.2007 kl. 12.59 -0700, skrev Kevan Benson:
>> When an afr encounters a file that exists on multiple shares that
>> doesn't have the trusted.afr.version set, it sets that attribute for sll
>> the files and assumes they contain the same data.
>> I.e. if you manually create the files on the servers directly and with
>> different content, appending to the file through the client will set the
>> trusted.afr.version for both files, and append to both files, but the
>> files still contain different content (the content from before the append).
>> Now, this would be really hard to replicate without this arbitrary
>> example, it would probably require a write fail to all afr subvolumes,
>> possibly at different times of the write operation, in which case the
>> file content can't be trusted anyways, so it's really not a big deal. I
> If I don't misunderstand this: I AFR for mirroring and HA. One side goes
> down - maintenance or (worse) HW crash. Some parts of some files
> somewhere are written, but maybe not all. When the server is coming back
> AFR selfheal can't really replicate the file, but will just append some
> of it? Or am I misunderstanding this?
Slightly. It seems when gluster finishes writing a file to an afr
subvolume, it sets the trusted.afr.version attribute for tracking when
files need to be updated, which is the most current, etc. This is
specific to the case where it isn't set on any afr subvoume, which would
require writing for fail to all of them for some reason. In that case,
if a file with the same name exists on both afr subvolumes without the
trusted.afr.version attribute, glusterfs doesn't sync the files one a
read, it just sets an initial trusted.afr.version on both files and
assumes they are the same.
The only working case I can think of that would trigger this is if there
was a complete failure of all afr subvolumes. The only other case where
people might run into this and not realize it would be if they were
pre-populating the afr subvolumes before going live (for example, using
rsync to replicate the active share that's being replaced by
glusterfs). This case could be worked around with a find that set the
trusted.afr.version attribute on all the files in the pre-populated
subvolume that's the newest in the afr.
It's really a non-issue, I just figured I'd mention it so people were
aware in case they ran into this, and in case the glusterfs team decided
this wasn't the preferred behavior for afr's when encountering files on
subvolumes that have no afr version tracking information.
More information about the Gluster-devel