Brent,
the write-behind mtime issue has more than one reason. the direct_io
related 'fix' got my system to work correctly with "cp -a", beause in
my binutils version of 'cp', the utimes() call is *after* the close(),
and the direct_io fix (which caused correct flush()ing) worked for me.
but you (and krishna) seem to have a newer version of binutils where
utimes() is called *before* the close(). utimes happens on the path
while write-behind is working over fd's. the right fix would be to
flush the 'held back' data during utimes() by relating the fd and the
path. for this 'relating' we need some enhancements in our code base
(which will be coming in as part of the 'supporting f**** calls'
task). Until then the 'cp -a' will continue to have the mtimes issue :(
the observation you have mentioned below confirms the theory since at
every 'aggregate-size' boundry a flush() is forced by write-behind
itself.
regards,
avati
On Tue, Apr 17, 2007 at 04:56:05PM -0400, Brent A Nelson 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
> >
>
--
ultimate_answer_t
deep_thought (void)
{
sleep (years2secs (7500000));
return 42;
}
