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.
The combination of mtime and ctime should actually be sufficient for
this. You can't back-date the ctime field via a system call. (Games
like larn used to use this so people couldn't cheat by copying and
restoring the save files.) Sure, people can still cheat by using
debugfs on the raw filesystem, but if you want to protect against a
superuser, you're going to have to resort to something cryptographic
(and slow), such as calculating an MD5 checksum over the whole file.
But for what you're trying to do, stashing the mtime and ctime field
should be quite sufficient.
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.
Well, that would only help directory entries. It wouldn't help all of
the other inodes in the filesystem. It adds a bit of kernel bloat, but
not that much. Submit a patch. :-)
[ Btw, the man pages say "-O sparse" but the programs want "-O
sparse_super".
Oops; thanks for catching that. I'll fix the man pages.
And are the "block bitmap differences" and "Free blocks
count wrong for <all groups>" messages ok after turning on
sparse_super? ]
Yes, the those errors are OK after turning on sparse_super.
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.
True; that should be pretty easy to get Linus to accept. Go for it, and
see if Linus will accept it. (I think he probably will).
I would prefer to see the full readdir() fixes in sooner rather than
later, but I can see why he might push back on that for 2.4.
> 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?
No, it doesn't, at least not at the moment.
- Ted
-
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/