Re: [patch 00/11] new truncate sequence

[Al Viro <viro@ZenIV.linux.org.uk>]

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.