From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chow Subject: Re: i_generation consistency Date: Thu, 28 Nov 2002 14:28:18 +0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3DE5B782.304@shaolinmicro.com> References: <3DE348C9.4000404@shaolinmicro.com> <15843.28685.348221.279411@notabene.cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: To: Neil Brown List-Id: linux-fsdevel.vger.kernel.org >>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