On Mon, 13 Jul 2009 07:07:18 -0500 (CDT) Vikas Gorur <[email protected]> wrote:
> > ----- "Stephan von Krawczynski" <[email protected]> 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. _______________________________________________ Gluster-users mailing list [email protected] http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
