> 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. Lu said:
>> 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.
Given what Linus says, perhaps the best solution is to do #2 for 2.2
in order to preserve module compatibility, and #1 for 2.3.
If we could do it in a way that the NFS filehandles remain the same
going from 2.2 to 2.3 for at least ext2, it would be ideal, I think.
Having all of your filehandles go south on you just because your Linux
NFS server was upgraded should happen as rarely as possible (never is
best, but I agree that we need to add the generation number, and I
don't know if we can add it without breaking filehandles once).
- Dan
-
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/