Re: [Gluster-devel] write-behind mtime glitch

[Krishna Srinivas]

Hi Brent,

You are right regarding the clue. As mentioned in one of my
previous emails, because of the caching, the cached data
is being written by write-behind after the utimes() call
hence mtimes. So any mtime changes by utimes() call
would be useless.

Regards
Krishna

On 4/18/07, Brent A Nelson <address@hidden> wrote:
> I found an additional clue to the write-behind mtime issue.  Some more
> copies again showed that zero-length files were getting proper mtime.
> Non-empty files again had an mtime associated with the copy EXCEPT for
> these two files:
>
> -rw-r--r-- 1 root root 131072 2006-07-11 08:48 
> /backup/usr0/share/samba/lowcase.dat
> -rw-r--r-- 1 root root 131072 2006-07-11 08:48 
> /backup/usr0/share/samba/upcase.dat
>
> Well, my write-behind has "option aggregate-size 131072"! I'm guessing
> that's not a coincidence...
>
> Thanks,
>
> Brent
>
> On Fri, 13 Apr 2007, Brent A Nelson wrote:
>
> > On Wed, 11 Apr 2007, Krishna Srinivas wrote:
> >
> >> Also regarding write-behind+mtime bug, can you check out the
> >> latest code and see if rsync or "cp -a" still sees the problem?
> >> Avati made has some changes.
> >>
> >
> > write-behind still has an mtime bug.  I "cp -a"'ed a /usr directory and all
> > non-empty files had file creation time/date for their mtime rather than the
> > original mtime.  Directories have the correct mtime, and zero-length files
> > have the correct mtime on both underlying filesystems, however, so this is
> > working.  But whenever it writes actual data, it seems like it must be doing
> > this after the mtime is set, changing the mtime, or the mtime is never
> > getting set.
> >
> > Thanks,
> >
> > Brent
> >
>
>
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gluster-devel