From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: i_generation consistency Date: Mon, 2 Dec 2002 10:00:58 +1100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <15850.38058.673480.590281@notabene.cse.unsw.edu.au> References: <3DE348C9.4000404@shaolinmicro.com> <15843.28685.348221.279411@notabene.cse.unsw.edu.au> <3DE5B746.1040300@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.233.231] == wireless-231.wireless.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Mon, 2 Dec 2002 10:01:00 +1100 To: David Chow In-Reply-To: message from David Chow on Thursday November 28 List-Id: linux-fsdevel.vger.kernel.org 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