From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: Re: [PATCH] replace inode_update_time with file_update_time Date: Mon, 7 Nov 2005 22:02:01 +0000 (GMT) Message-ID: References: <20051029165209.GA26446@lst.de> <1131400349.8063.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Christoph Hellwig , akpm@osdl.org, linux-fsdevel@vger.kernel.org Return-path: Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]:18617 "EHLO ppsw-9.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S965230AbVKGWCO (ORCPT ); Mon, 7 Nov 2005 17:02:14 -0500 To: Shaya Potter In-Reply-To: <1131400349.8063.7.camel@localhost.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 7 Nov 2005, Shaya Potter wrote: > On Mon, 2005-11-07 at 21:40 +0000, Anton Altaparmakov wrote: > > On Sat, 29 Oct 2005, Christoph Hellwig wrote: > > > To allow various options to work per-mount instead of per-sb we need > > > > What are those various options? Please spell them out. (I mean it! I > > really do not know what you have in mind and I cannot see anything that > > would require a vfs mount wrt cmtime updates.) > > I'm thinking you should think of things like read only bind mounts, > where even meta data wont be updated. But that is my point! A read-only bind mount is just like any other read-only mount and should never even try to update metadata. Which codepaths cause inode/file_update_time() to be called for a read-only mount? I do not believe there are any! And assuming that I am correct this makes the IS_RDONLY() check pointless and this in turn makes the whole patch pointless and given it breaks existing file systems it should be sent to the nirvana of useless patches. Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/