On Sat, Jul 23, 2011 at 08:59:15AM +1000, NeilBrown wrote:

On Fri, 22 Jul 2011 18:31:58 -0400 "J. Bruce Fields" [off-list ref]
wrote:

quoted

On Fri, Jul 22, 2011 at 06:10:39PM -0400, bfields wrote:

quoted

On Fri, Jul 22, 2011 at 11:47:32PM +0200, Andi Kleen wrote:

quoted

On Fri, Jul 22, 2011 at 04:11:42PM -0500, Matt Mackall wrote:

quoted

On Fri, 2011-07-22 at 22:59 +0200, Andi Kleen wrote:

quoted

quoted

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.)

But does anyone apart from NFSv4 actually *want* i_version as opposed to the
more-generally-useful precise timestamps?

It *seems* like a generally useful idea, but I don't know of any other
users.

If not, we probably should tell NFSv4 to use timestamps and focus on making
them work well.
??

Well, sure, I couldn't complain about that if that proved possible.

--b.

The timestamp used doesn't need to update ever nanosecond.  I think if it
were just updated on every userspace->kernel transition  (or effective
equivalents inside kernel threads) that would be enough capture all
causality.  I wonder how that would be achieved..  I wonder if RCU machinery
could help - doesn't it keep track of when threads schedule ... or something?

NeilBrown