Re: Re: write-behind mtime glitch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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;
}




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux