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.
