Messages in this thread | | | Date | Wed, 3 Nov 1999 09:08:44 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: structure dentry help... |
| |
Date: Wed, 3 Nov 1999 14:29:41 +0100 From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
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/
| |