Re: [RFC] new ->perform_write fop

[Nick Piggin <npiggin@suse.de>]

On Mon, May 24, 2010 at 11:20:34AM +0200, Jan Kara wrote:
> On Sat 22-05-10 10:27:59, Dave Chinner wrote:
> > On Fri, May 21, 2010 at 08:58:46PM +0200, Jan Kara wrote:
> > > On Fri 21-05-10 09:05:24, Dave Chinner wrote:
> > > > On Thu, May 20, 2010 at 10:12:32PM +0200, Jan Kara wrote:
> > > > >   b) E.g. ext4 can do even without hole punching. It can allocate extent
> > > > >      as 'unwritten' and when something during the write fails, it just
> > > > >      leaves the extent allocated and the 'unwritten' flag makes sure that
> > > > >      any read will see zeros. I suppose that other filesystems that care
> > > > >      about multipage writes are able to do similar things (e.g. btrfs can
> > > > >      do the same as far as I remember, I'm not sure about gfs2).
> > > > 
> > > > Allocating multipage writes as unwritten extents turns off delayed
> > > > allocation and hence we'd lose all the benefits that this gives...
> > >   Ah, sorry. That was a short-circuit in my brain. But when we do delayed
> > > I don't see why we should actually do any hole punching... The write needs
> > > to:
> > >   a) reserve enough blocks for the write - I don't know about other
> > > filesystems but for ext4 this means just incrementing a counter.
> > >   b) copy data page by page
> > >   c) release part of reservation (i.e. decrement counter) if we actually
> > > copied less than we originally thought.
> > > 
> > >   Am I missing something?
> > 
> > Possibly. Delayed allocation is made up of two parts - space
> > reservation and recording the regions of delayed allocation in an
> > extent tree, page/bufferhead state or both.
>   Yes. Ext4 records the info about delayed allocation only in buffer
> heads.
> 
> > In XFS, these two steps happen in the same get_blocks call, but the
> > result of that is we have to truncate/punch delayed allocate extents
> > out just like normal extents if we are not going to use them. Hence
> > a reserve/allocate interface allows us to split the operation -
> > reserve ensures we have space for the delayed allocation, allocate
> > inserts the delayed extents into the inode extent tree for later
> > real allocation during writeback. Hence the unreserve call can
> > simply be accounting - it has no requirement to punch out delayed
> > extents that may have already been allocated, just do work on
> > counters.
> > 
> > btrfs already has this split design - it reserves space, does the
> > copy, then marks the extent ranges as delalloc once the copy has
> > succeeded, otherwise it simply unreserves the unused space.
> > 
> > Once again, I don't know if ext4 does this internal delayed
> > allocation extent tracking or whether it just uses page state to
> > track those extents, but it would probably still have to use the
> > allocate call to mark all the pages/bufferheads as delalloc so
> > that uneserve didn't have to do any extra work.
>   Yes, exactly. I just wanted to point out that AFAICS ext4 can implement
> proper error recovery without a need for 'punch' operation. So after all
> Nick's copy page-by-page should be plausible at least for ext4.

Great. AFAIKS, any filesystem that does not leak uninitialized data
on IO error or crash when allocating writeback cache over holes
should already have enough information to recover properly from
short-copy type of error today.

Otherwise, an IO error or crash seems like quite a similar problem
from the point of view of the filesystem. Now perhaps it can be
recovered only in a fsck type operation which is far too expensive
to do in a normal error path, which sounds like XFS.

So possibly we could have 2 APIs, one for filesystems like XFS, but
I don't think we should penalise ones like ext4 which can handle
this situation.