linux-kernel - Re: Nanosecond fs timestamp support: sad

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110722221039.GB10749@fieldses.org>
Date:	Fri, 22 Jul 2011 18:10:39 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Matt Mackall <mpm@...enic.com>, NeilBrown <neilb@...e.de>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Nanosecond fs timestamp support: sad

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.  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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/