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 only mention it in case it might not be the desired behavior, and because it might be useful to have the first specified afr subvolume supply the file to the others in the case that none has the trusted.afr.version attribute set in cases of pre-populating the share (such as rsyncs from a dynamic source). The problem is easily mitigated (rsync to a single share and trigger a self-heal or rsync to the client mount point), I just figured I'd mention it, and that's only required if you really NEED pre-population of data.
-- -Kevan Benson -A-1 Networks
