linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: npiggin@suse.de, Andrew Morton <akpm@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [patch 00/11] new truncate sequence
Date: Wed, 23 Sep 2009 03:29:21 +0100	[thread overview]
Message-ID: <20090923022921.GK14381@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20090922235845.GJ14381@ZenIV.linux.org.uk>

On Wed, Sep 23, 2009 at 12:58:45AM +0100, Al Viro wrote:
> On Wed, Sep 23, 2009 at 12:27:42AM +0100, Al Viro wrote:
> > On Tue, Sep 22, 2009 at 10:51:38PM +0100, Al Viro wrote:
> > > It is...  I really don't like some parts of that:
> > > 	* failing on foo_truncate() is all nice and proper, but
> > > what to do about the quota transfer that has already happened?
> > > Note that e.g. ext2_setattr() simply doesn't change uid/gid in
> > > case of ext2_setsize() failure.  It does transfer quota, though.
> > > And yes, nfsd can produce calls with both ATTR_SIZE and ATTR_UID
> > > set.
> > > 	* way, _way_ too much boilerplate around the aforementioned
> > > quota transfers.
> > > 	* if we don't do quota handling for minix and sysv (fair enough,
> > > no quota support implemented for those), why the devil are we doing it
> > > in simple_setattr()?
> > > 
> > > Anyway, #new-truncate in the usual VFS tree contains all "new truncate
> > > scheme" stuff I've collected from the lists so far.  Additions are welcome...
> > 
> > BTW, why are we messing with truncation in ->write_end() e.g. for ext2?
> 
> BTW^2, what's going to unmap the stale buffers in the page if
> ext2_write_begin() runs into an error?  ext2_truncate() (and thus vmtruncate()
> that used to be called from block_write_begin()) used to do that, but
> ext2_truncate_blocks() won't...
> 
> Frankly, I'm almost 100% convinced to postpone new-truncate merge until
> .33-rc1; the first couple of patches (vmtruncate() unification and cleanups)
> can go right now, but the rest obviously hadn't been beaten up enough
> to seriously consider it for .32-rc1.

FWIW, I think that a reasonable battle plan for that series would look so:
	* current first two patches
	* vmtruncate()-less analogs of block_write_begin(), nobh_write_begin()
and blockdev_direct_IO(); original 3 functions themselves become wrappers.
	* default_setattr()
	* sort out the use of vmtruncate() in ecryptfs.
	* at that point work on individual filesystems becomes independent;
we can convert them one by one at leisure, killing vmtruncate() uses in
each as we go.  Basically, take an fs, shift vmtruncate() calls into the
methods (we will have full set of needed helpers) and lambda-expand each
(remember that vmtruncate() becomes a straightforward short sequence of helper
calls after the first stage).  And replace that ->truncate() call with
explicit foofs_truncate(), switching .truncate to NULL while we are at it.
All equivalent transformations, all independent.  Massage foo_setattr()
as we wish.
	* once we are done, remove vmtruncate() and ->truncate() - no more
callers for them.  Ditto for leftover 3 wrappers.

AFAICS, that gives a bisectable series with no "new_truncate" flags, with
no flagday interface changes at all and mergable just fine piecewise.

Comments?

  reply	other threads:[~2009-09-23  2:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-20 16:35 [patch 00/11] new truncate sequence npiggin
2009-08-20 16:35 ` [patch 01/11] fs: new truncate helpers npiggin
2009-08-26  7:38   ` Artem Bityutskiy
2009-09-07  7:33     ` Nick Piggin
2009-09-07  7:48       ` Artem Bityutskiy
2009-08-20 16:35 ` [patch 02/11] fs: use " npiggin-l3A5Bk7waGM
2009-08-20 16:35 ` [patch 03/11] fs: introduce new truncate sequence npiggin
2009-08-26  7:40   ` Artem Bityutskiy
2009-08-20 16:35 ` [patch 04/11] fs: convert simple fs to new truncate npiggin
2009-08-20 16:35 ` [patch 05/11] tmpfs: convert to use the new truncate convention npiggin
2009-08-20 16:35 ` [patch 06/11] ext2: " npiggin
2009-08-21 13:42   ` Jan Kara
2009-08-21 14:06     ` Jan Kara
2009-08-24  5:30       ` [patch] ext2: convert to use the new truncate convention fix Nick Piggin
2009-08-20 16:35 ` [patch 07/11] fat: convert to use the new truncate convention npiggin
2009-08-20 16:35 ` [patch 08/11] btrfs: " npiggin
2009-08-20 16:35 ` [patch 09/11] jfs: " npiggin
2009-08-20 16:35 ` [patch 10/11] udf: " npiggin
2009-08-21 14:22   ` Jan Kara
2009-08-24  5:33     ` Nick Piggin
2009-08-20 16:35 ` [patch 11/11] minix: " npiggin
2009-09-09  7:11 ` [patch 00/11] new truncate sequence Artem Bityutskiy
2009-09-22 15:04 ` Al Viro
2009-09-22 20:00   ` Christoph Hellwig
2009-09-22 21:51     ` Al Viro
2009-09-22 23:27       ` Al Viro
2009-09-22 23:58         ` Al Viro
2009-09-23  2:29           ` Al Viro [this message]
2009-09-27 19:50             ` Nick Piggin
2009-12-07 12:49             ` Nick Piggin
2009-12-07 22:46               ` Tyler Hicks
2009-09-22 20:53 ` [PATCH 12/n] kill spurious reference to vmtruncate Christoph Hellwig
2009-09-22 20:54 ` [PATCH 13/n] xfs: new truncate sequence Christoph Hellwig
2009-09-22 20:55 ` [PATCH 14/n] sysv: " Christoph Hellwig
2009-09-22 20:56 ` [PATCH 15/n] ntfs: " Christoph Hellwig

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=20090923022921.GK14381@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /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).