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
address@hidden
http://lists.nongnu.org/mailman/listinfo/gluster-devel
--
ultimate_answer_t
deep_thought (void)
{
sleep (years2secs (7500000));
return 42;
}