i_generation consistency

i_generation consistency

[David Chow]

Hi Neil,

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.

regards,
David Chow

Re: i_generation consistency

[Neil Brown]

On Tuesday November 26, davidchow@shaolinmicro.com wrote:
> Hi Neil,
> 
> 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

Re: i_generation consistency

[David Chow]

>>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

Re: i_generation consistency

[Neil Brown]

On Thursday November 28, davidchow@shaolinmicro.com wrote:
> 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?

Yes, your understanding is correct.  If filesystems set i_generation
to something that is not stable, they would work well when exported
via knfsd.

NeilBrown