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/