Re: Nanosecond fs timestamp support: sad

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Jul 22, 2011 at 06:10:39PM -0400, bfields wrote:
> On Fri, Jul 22, 2011 at 11:47:32PM +0200, Andi Kleen wrote:
> > On Fri, Jul 22, 2011 at 04:11:42PM -0500, Matt Mackall wrote:
> > > On Fri, 2011-07-22 at 22:59 +0200, Andi Kleen wrote:
> > > > > Indeed. Only usefully exists on ext4 and requires extra system calls.
> > > > 
> > > > Not sure what you mean?  It's in stat(2), just like the timestamps.
> > > 
> > > I don't see anything that looks like a version or generation number in
> > > either the man pages, the asm-generic/stat.h, or glibc's asm/stat.h.
> > > Pointer?
> > 
> > Hmm you're right. I thought it was in there, but apparently not.
> > I think it should be added there though. We still have some unused 
> > fields.
> 
> But last I checked I thought it was only ext4 that actually incremented
> the i_version on IO, and even then only when given a (non-default) mount
> option.
> 
> My notes on what needs to be done there:
> 
> 	- collect data to determine whether turning on i_version causes
> 	  any significant performance regressions.
> 		- Last I talked to him, Ted Tso recommended running
> 		  Bonnie on a local disk, since it does a lot of little
> 		  writes, which is somewhat of a worst case, as it will
> 		  generate extra metadata updates for each write.
> 		  Compare total wall-clock time, number of iops, and
> 		  number of bytes (using some kind of block tracing).
> 	- If there aren't any problems, turn it on by default, and we're
> 	  done.

(Well,and talk the other filesystem implementors into doing it.)

--b.

>	  If there are unfixable problems, consider something
> 	  more complicated (like turning on i_version automatically when
> 	  someone asks for it).
> 	- We need to check that i_version is also doing something
> 	  sensible on directory as well as on file inodes.
> 	- We also need to think about what it does after reboots.  (E.g.
> 	  what is an nfs server to do if clients see the i_version go
> 	  backwards (and hence possible repeat old values) after a
> 	  reboot?)
> 	- Double-check the order that data updates and i_version updates
> 	  are done in.  (Ideal would be if they were atomic, but for
> 	  nfsd's purposes at least it should be adequate if the
> 	  i_version comes after, and no later than the next commit.)
> 
> --b.