[RFC] inode generation numbers.

G. Allen Morris III (gam3@harpo.ixlabs.com)
Mon, 22 Feb 1999 18:50:40 -0800

Are there any adverse effects to adding a field to `struct inode'?
I would like to add `u32 i_generation' for the reasons outlined

NFS is in need of an inode generation number for correctness and
possibly some added security. The best way to do this is by adding
a u32 variable to struct inode.

H.J. originally was going to put jiffies into this field, and so
he named the variable i_timestamp, however i_generation seems
a more descriptive name. But I will gladly take suggestions.

The value that is put into this field will be up to each filesystem.
The only requirement is that the generation count only change if
i_nlink reaches zero (the file is deleted).

No change will be needed to filesystems that do not wish to, or
can't supply a generation count.

kernel NFSD needs this for the case where a file is deleted and
then a new file is created with the same ino. An attempt to access
the original file should fail, and not read the new file. This is
a problem on ext2 because it likes to reuse an inode that was just
deleted. On systems that use a round-robin aproach to selecting
an inode this is not as important.

The added security comes from the fact that the client either
has to make a call to MOUNT or has to guess the generation
count of an inode.

>>>H.J. Lu said:
> Linus, can we make a decision on what we should do about the generation
> count. There are 2 approaches now:

> 1. Mine adds i_timestamp to "struct inode" and let each file system decide
> what to do with it. If it doesn't support it in inode on disk, it can just
> reset the count. It means less than 5 line change per each file system.

> 2. Allen changes nfsd to access the ext2 internal directly bypass the VFS
> layer. You don't need to change other file systems if they don't support
> i_timestamp in inode on disk. But it looks very ugly to me.


G. Allen Morris III

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/