Brent,
a simpler solution for your mtime issue would be to set the
aggregate-size to 0, so that every write is instantly written behind
(and not held back for aggregatino). the performance difference
brtween write-behind v/s write-behind+aggregatoin is very marginal for
most practical purposes. hope that helps,
avati
On Wed, Apr 18, 2007 at 09:10:59AM -0700, Anand Avati wrote:
> 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;
> }
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxx
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
--
ultimate_answer_t
deep_thought (void)
{
sleep (years2secs (7500000));
return 42;
}
