linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: akpm@osdl.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] replace inode_update_time with file_update_time
Date: Tue, 8 Nov 2005 09:50:36 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0511080947310.30743@hermes-1.csi.cam.ac.uk> (raw)
In-Reply-To: <20051108043054.GA8531@lst.de>

On Tue, 8 Nov 2005, Christoph Hellwig wrote:
> On Mon, Nov 07, 2005 at 09:40:51PM +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.)
> 
> The ones I work now are noatime and read-only.

noatime is not dealt with at all in file/inode_update_time().

read-only check should be removed altogether.

Anything else?  (-:

> > I believe your patch is wrong/unnecessary because the only option that is 
> > per superblock (or in your new world per vfsmount) is the IS_RDONLY(inode) 
> > check and if a mount is read-only the VFS should never have allowed 
> > inode/file_update_time() to be called.  The codepath should have been 
> > aborted _much_ earlier than that so it does not make any sense to test for 
> > read-only here thus it is not necessary to do a per mountpoint check.  
> > Instead we should remove the readonly check altogether and if there are 
> > any places where an update of cmtime is attempted on a read-only mount we 
> > should fix those instead...
> > 
> > A more detailed justification for your patch is IMO required before it be 
> > applied to mainline, especially as it breaks existing file systems like 
> > ntfs (as discussed offlist).
> 
> Besides the above usage it's a nice cleanup and already found bugs like
> the API abuse in ntfs ->truncate.

I don't think it is a nice cleanup at all.  It is an inode operation not a 
file operation no matter what you say about it...

And if you don't want this to be used from anywhere other than file write 
& co, you ought to put a comment to that effect on it.  To me it seems the 
exact function one _should_ call rather than doing it oneself because it 
does the optimisations, etc, for free, without having to duplicate the 
whole function like you did to "fix" ntfs.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (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/

      reply	other threads:[~2005-11-08  9:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-29 16:52 [PATCH] replace inode_update_time with file_update_time Christoph Hellwig
2005-10-31 22:54 ` Andrew Morton
2005-10-31 22:57   ` Christoph Hellwig
2005-11-07 21:40 ` Anton Altaparmakov
2005-11-07 21:52   ` Shaya Potter
2005-11-07 22:02     ` Anton Altaparmakov
2005-11-07 22:10       ` Shaya Potter
2005-11-07 22:13         ` Anton Altaparmakov
2005-11-08  4:34       ` Christoph Hellwig
2005-11-08  9:52         ` Anton Altaparmakov
2005-11-08  4:30   ` Christoph Hellwig
2005-11-08  9:50     ` Anton Altaparmakov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0511080947310.30743@hermes-1.csi.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).