Re: i_generation consistency

[David Chow <davidchow@shaolinmicro.com>]

>>I am writing a file system and having problem implementing the 
>>i_generation of the inode. Should the i_generation be persistent in the 
>>disk? Or it has to be changed every time the dcache shrinks or reload 
>>after read_inode()? Should I check the i_generation in the fh_dentry() 
>>ops and include it in file handle or leave it to the NFS clients and 
>>nfsd and I should forget about implementing i_generation in file 
>>handles. Can you please clarify? Thanks.
>>    
>>
>
>The core requirement is that dentry_to_fh must provide a
>filehandle that fh_to_dentry can
>  1/ recoginise and find, even if it isn't in cache
>  2/ check that the inode that was found is still valid. i.e.
>    that it hasn't been re-used after the original was deleted.
>
>This is sometimes done using a combination of 
>inode number, that can be used to locate a file, but that can be 
>reused after a file is removed, and a generation number,
>that is stored in the inode and has a different value each time the 
>inode is reused (though this is not the only way to do it).
>
>In this case, the generation number must be stored on stable
>storage, and should be checked in fh_to_dentry.
>
>Hope this helps.
>
>NeilBrown
>
Thanks, it seems some file system change the i_generation each time the 
inode is read ... I don't think this is a good idea because the server 
can shrink the dcache and got the inode flushed, while the client keep 
that i_generation in its dcache. The next time the client requests that 
inode using the old i_generation and find it is stale. That means the 
lifetime of an i_generation is the same as the dcache which is not 
persistent. But from what you say is that the i_generation should be 
kept persistent until it is reused after a remove or delete, is my 
understanding right?

regards,
David