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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html