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 <brent@xxxxxxxxxxxx> 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 Gluster-devel@xxxxxxxxxx http://lists.nongnu.org/mailman/listinfo/gluster-devel
