Re: [patch 12/16] fix race between writeback and unlink

[Andrew Morton <akpm@zip.com.au>]

Chris Mason wrote:
> 
> On Mon, 2002-06-03 at 18:19, Linus Torvalds wrote:
> >
> >
> > On 3 Jun 2002, Chris Mason wrote:
> > >
> > > Or am I missing something?
> >
> > No. I think that in the long run we really would want all of the writeback
> > preallocation should happen in the "struct file", not in "struct inode".
> > And they should be released at file close ("release()"), not at iput()
> > time.
> 
> reiserfs does preallocation and tail packing in release() right now, but
> do we really need preallocation at all once delayed allocation is
> stable?
> 

well..  Will delayed allocation even exist?  Grafting reservations
onto ext2 had a few awkward moments in the area of handling ENOSPC,
and generally a lot of the benefits of that code (ie: avoiding buffers)
have been whittled away by other means.

So right now I don't see a strong reason for adding delayed allocation
support into the core kernel for ext2.  If another fs comes up and
creates a demand for core kernel support then fine.  (Thinking XFS
here).  Probably I should resurrect the ext2 code as something for you
and Steve to poke at.

Plus ext3 needs prealloc as well.  Performing that within the live
bitmaps like ext2 is really awkward.  I have half-a-patch which performs
area reservations in ext3 via a per-private-inode "start, length"
tuple.  These zones never get near being written to disk.  That
seems a reasonable approach for ext3, but it does use the inode.
If that info was inside struct file, writepage() would get rather
confused - it doesn't have a file*.

-