gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Timestamp/metadata sync


From: Gordan Bobic
Subject: Re: [Gluster-devel] Timestamp/metadata sync
Date: Tue, 03 Mar 2009 11:36:02 +0000
User-agent: RoundCube Webmail/0.2

On Tue, 3 Mar 2009 16:59:33 +0530, Anand Avati <address@hidden>
wrote:
>> 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?

I haven't checked since the upgrade from rc1 to rc2, I'll re-test.

>> 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.

Ah, OK, that makes sense. But it still doesn't explain why for some files
the old, deprecated xattrs were getting replicated, and for some they
weren't.

>> 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?

I was referring to the data in the xattrs. The weird thing was that
sometimes the old xattr flags were being synced to the new node and
sometimes they weren't.

Gordan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]