I mean from day to day, or week to week across reboots, and over more
files than you can have open at once. Perhaps all the files.
mtime doesn't work -- mtime asks the wrong question. I can't trust
mtime for operations such as:
- updatedb (go faster by ignoring unchanged directory trees)
- rpm -Va (no need to recalculate md5 sums)
- transparent dynamic recompilation cache (should behave as if it
reads the file it is recompiling every time)
The point is to be able to simulate the effect of really reading
something, without reading it if I have cached results in a database
already, and without being prone to going wrong just because someone's
computer is fast or they enjoy the `touch' command.
> In e2fsprogs 1.17, you can turn it on as follows:
>
> tune2fs -O filetype /dev/XXX
>
> ... and then running e2fsck. The 1.17 e2fsck will populate the d_type
> information if it's not set.
Woo-hoo! <looks at e2fsprogs release notes> I see that you've
done everything I had hoped to convince you to do :-) Very nice.
e2fsck is a bit verbose during the conversion though...
Is it worth having the kernel ext2fs automatically convert DT_UNKNOWN
directory entries as it encounters them (during lookup)? That would
allow the time-consuming conversion step to be skipped.
[ Btw, the man pages say "-O sparse" but the programs want "-O
sparse_super". And are the "block bitmap differences" and "Free blocks
count wrong for <all groups>" messages ok after turning on sparse_super? ]
> Of course, until the kernel is patched to provide a new readdir() system
> call passes that information to userland, and glibc is updated to use
> the new system call, it's not all that useful, but the support is
> there.
Much of it has been written already, and for most filesystems.
For "find" style operations where you simply want a list of names (plus
`-type d' tests), a speedup is possible without any kernel/user API
change. Do you remember the patch to speed up `open (fn, O_DIRECTORY)'
by avoiding inode reads for non-directories? Your tune2fs feature is
the step that makes that patch effective. I will try it on a real
filesystem soon, and see how much faster treescan runs.
> Note that once you turn on the filetype filesystem feature, the
> filesystem will not be compatible with Linux 2.0 kernels! (I do have a
> patch which will allow 2.0 kernel to support newer ext2 features;
> contact me if you're interested).
Ew. I thought the compatibility part was older.
> This is why the Linux 2.2 ext2fs actually had d_type implemented
> (minus the user-space VFS interface), but earler e2fsprogs didn't turn
> it on or have any support for it. The original plan was to wait until
> Linux 2.4 to turn on d_type support. (It's now a little bit late
> given the feature freeze, but maybe Linus could be pursuaded to slip
> it in.)
It is not very pretty, but the O_DIRECTORY speedup patch is small and
doesn't change any APIs. It's just a kernel optimisation. So it is not
a feature :-) I will try it out.
> P.S. You can also turn off the filetype information by using the
> command "tune2fs -O ^filetype", and then re-running e2fsck. This will
> allow the filesystem to be mounted by an unpatched Linux 2.0 kernel.
Very good. Does this revert the superblock version number to old-style
too, for mounting with even older kernels?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/