>>>>> " " == Theodore Y Ts'o <tytso@MIT.EDU> writes:
> Would it perhaps make sense to use one of these last 'free'
> fields as a pointer to an 'inode entension'? If you still
> want ext2fs to be able to accommodate new projects and
> ideas, then it seems that being able to extend the inode is
> a desirable feature, but perhaps this overlaps with the
> apparent plans for adding resource forks?
> For stuff that's not commonly used, perhaps. The problem is
> that you take a speed hit when you have to seek somewhere else
> to get at the inode extension. So for something which is going
> to have to be referenced for every stat() or getattr()
> operation, there are a real performance issues with doing
> something like that.
For the timestamps, yes, but inode caching will take most of that
hit. After all, the only time stat() reads from disk is when the inode
has completely fallen out of the cache.
I agree that doing something like this is less than ideal, but given
that the ext2fs inode space hunt seems to be a frequently recurring
issue it should be considered as an alternative that gives us whatever
space we need for 3 full-sized timestamps and possibly for any future
ext2fs projects while preserving backward compatibility.
Of course, as I said: when suggesting this, I'm moving completely out
of my depth. I'm not ready to argue seriously for or against anything
whatsoever, but I'd appreciate an informed opinion.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:23 EST