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