Stephan von Krawczynski
skraw at ithnet.com
Mon Jul 13 12:44:58 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
> 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).
More information about the Gluster-users