[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 wrote:
> Date: Thu, 14 Sep 2000 15:09:35 +0200 (CEST)
> From: Trond Myklebust <>
> 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.

The "right" way to do this is to have a "this spot is in use, but you
don't understand it" indication for an inode (*). The "expansion ptr"
can then normally point to the directly following inode, but also
somewhere completely different.

So a "new" system would allocate a new inode in the directly following
spot. But when a "new" system would need the extension part on an old
filesystem, it would allocate the nearest inode and point the
extension ptr there.


(*) Actually the kernel only needs the "it's in use" part. fsck needs
to know what it means or to properly ignore it....

** ** ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
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.021 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site