[Gluster-users] 2.0.3 (info added)
Stephan von Krawczynski
skraw at ithnet.com
Mon Jul 13 12:52:39 UTC 2009
On Mon, 13 Jul 2009 07:07:18 -0500 (CDT)
Vikas Gorur <vikas at gluster.com> wrote:
>
> ----- "Stephan von Krawczynski" <skraw at ithnet.com> wrote:
>
> > Hello,
> >
> > this bug is _not_ fixed in 2.0.4. We just tried and the problem stays
> > the same.
> > All you have to do to reproduce is:
> > - take 2 servers with replicate
> > - copy data (with directories) onto first servers glusterfs exported
> > dir.
> > - do ls -lR on client, self healing on second server starts.
> > - when self-healing is done look at second servers exported dir.
> > find all healed directories with current timestamp from healing and
> > not with timestamp from original on first server.
>
> If you look closely, you'll see that the mtime is consistent, while the atime
> and ctime might have changed. This is because:
>
> * atime -- This is the access time. This will change with every access ("ls" or read),
> and hence even though it is synchronized during self-heal, it will obviously change
> the next time you do any access operation.
>
> * ctime -- This is the inode change time. This is entirely under the control of the kernel
> and there is no system call in Unix that allows us to change it. Hence we cannot synchronize
> this.
>
> There was indeed a bug in the previous versions which would leave mtime inconsistent too, and
> that has been fixed.
Sorry to say that. But if I rsync the trees they end up with _correct_ (i.e.
identical) timestamp displayed at standard "ls".
Whereas using self-heal shows different timestamps on "ls".
This at least proves that the stamps I mean are settable by user-space tools
(like rsync).
> Vikas
--
Regards,
Stephan
PS: the comparison with rsync brought to my mind that you may try to do things
wrong way round. Are you sure to set the timestamps _after_ you fiddled around
inside the directories? If you look at rsync you find out that it sets all dir
timestamps at the very end of all other file operations.
More information about the Gluster-users
mailing list