From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: i_generation consistency Date: Tue, 26 Nov 2002 23:58:53 +1100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <15843.28685.348221.279411@notabene.cse.unsw.edu.au> References: <3DE348C9.4000404@shaolinmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: From notabene.cse.unsw.edu.au ([129.94.242.45] == bartok.orchestra.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Tue, 26 Nov 2002 23:59:01 +1100 To: David Chow In-Reply-To: message from David Chow on Tuesday November 26 List-Id: linux-fsdevel.vger.kernel.org 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