[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 17:12:35 +0200 (MEST)
> From: (Rogier Wolff)
> 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.
> Storing the excess data in the inode table is one way to do it. But if
> every single inode is going to need the extra data, you've effectively
> halved the size of the inode table, and running out of inodes becomes a
> serious concern.
> If we really want to store more data, in the long run it'll probably be
> a lot faster to simply double the inode size, and write an off-line
> program which can move datablocks out of the way and then double the
> size of the inode table.

My suggestion is indeed effectivly (almost) doubling the inode size.

However, it provides an upgrade path, where you can double-boot with a
kernel that DOESN"T know about the inodes.


** ** ** +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.025 / U:1.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site