From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: i_version changes Date: Wed, 13 Feb 2008 16:32:08 -0500 Message-ID: <47B361D8.1070708@redhat.com> References: <20080210073041.GA23529@lst.de> <20080212200625.GE18625@fieldses.org> <20080213125214.GA12362@lst.de> <20080213202611.GM13462@fieldses.org> <43290.192.168.1.70.1202937559.squirrel@neil.brown.name> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "J. Bruce Fields" , Christoph Hellwig , jean-noel.cordenner@bull.net, linux-fsdevel@vger.kernel.org To: NeilBrown Return-path: Received: from mx1.redhat.com ([66.187.233.31]:59917 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765532AbYBMVcq (ORCPT ); Wed, 13 Feb 2008 16:32:46 -0500 In-Reply-To: <43290.192.168.1.70.1202937559.squirrel@neil.brown.name> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: NeilBrown wrote: > On Thu, February 14, 2008 7:26 am, J. Bruce Fields wrote: > > >> It's not OK to update it only sometimes. If updates are made while nfsd >> isn't running, those needed to be reflected in the change attribute, so >> the changes aren't missed when nfsd comes back up. >> > > For NFSD's needs, it is only necessary that changes in i_version that are > potentially visible over NFS actually be stored on disk. > > You could come up with an interface where NFSD sets a flag when it reads > i_version, and changes to the file only change i_version if the flag is > set (at which point the flag is cleared). > > This would give fully correct NFS semantics, and no overhead when NFS access > is not in use > > I don't think that this is quite true. If the file is changed when the NFS server is not running, then the value of i_version which is used when the NFS server starts up again must be different than the value which was previously used when the NFS server was previously running. Is the perceived performance hit really going to be as large as suspected? We already update the time fields fairly often and we don't pay a huge penalty for those, or at least not a penalty that we aren't willing to pay. Has anyone measured the cost? Thanx... ps > This flag would need to be stored in stable storage too, so probably easiest > to make it the least significant bit of i_version. > > Of course then the semantics of the new i_version are very different to > the old i_version, so maybe we need two fields in the inode.... > > NeilBrown > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >