[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
>>>>> " " == 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.050 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site