Messages in this thread | | | Subject | [RFC] inode generation numbers. | Date | Mon, 22 Feb 1999 18:50:40 -0800 | From | "G. Allen Morris III" <> |
| |
Are there any adverse effects to adding a field to `struct inode'? I would like to add `u32 i_generation' for the reasons outlined below.
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.
Allen
--------------------------------- 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/
| |