> OK, last post for this week, I promise.
>
> Are the timestamps in the backing store supposed to be the same on all
> nodes after syncing? Files were just synced from the master node
> (primarly lock server). The master has files with a timestamp
> 1-Jan-1970. The secondary node that just synced them has the current
> timestamp on the files (17-Feb-2009).
Do you still observe this with the latest codebase?
> The gluster metadata doesn't match, either:
>
> primary:
> # file: spreadsheet.ods
> trusted.glusterfs.afr.data-pending=0sAAAAAAAAAAAAAAAA
> trusted.glusterfs.afr.metadata-pending=0sAAAAAAAAAAAAAAAA
> trusted.glusterfs.createtime="1218717518"
> trusted.glusterfs.version="11"
>
> secondary:
> getfattr -m "" -d spreadsheet.ods
> # file: spreadsheet.ods
> trusted.glusterfs.afr.data-pending=0sAAAAAAAAAAA=
glusterFS 2.0 relies upon pending flags and versions are no more used.
> md5 checksums of the files match, so the contents are the same.
>
> When both servers are up, the timestamp lists correctly (1-Jan-1970). When
> the primary gets shut down, ls lists the timestamp of the file on the
> secondary server (17-Feb-2009).
>
> When the primary server returns, the secondary starts listing the timestamp
> correctly again. cat-ing all the files doesn't "heal" the discrepancy.
>
> The file sync was done by
> # ls -laR /mount/path; find /mount/path -type f -exec head -c1 '{}' \;
>
> The really weird thing is that this doesn't seem to happen to all the files,
> but it does appear to happen to a very large number of them. The master
> seems to have valid sattr metadata, but the newly synced mirror doesn't,
> even though the content of the files in the backing store is correct.
>
> It is also worth noting that the timestamp discrepancy seems to have the
> incidence of nearly 100%. The metadata discrepancy seems to be occuring
> considerably less often.
By metadata do you mean ownership and permission?
Avati
