Re: O_TRUNC problem on a full filesystem

[Andrew Morton <andrewm@uow.edu.au>]

Andreas Dilger wrote:
> 
> Andrew writes:
> > "Stephen C. Tweedie" wrote:
> > > On Wed, May 23, 2001 at 07:55:48PM +1000, Andrew Morton wrote:
> > > > When you truncated your file, the blocks remained preallocated
> > > > on behalf of the file, and were hence considered "used".  For
> > > > some reason, a subsequent attempt to allocate blocks for the
> > > > same file failed to use that file's preallocated blocks.
> > >
> > > Nope.  ext2_truncate() calls ext2_discard_prealloc() to fix this up.
> > > Both 2.2 and 2.4 do this correctly.
> >
> > But the problem goes away when you disable EXT2_PREALLOCATE.
> > I tested it.
> 
> Are you sure that a truncated file will re-use the same truncated blocks,
> but not the preallocated ones?  I can imagine not re-using all of the data
> blocks within a single transaction, but it would be odd if the preallocated
> blocks are treated differently.

This is vanliia ext2.  The O_TRUNC problem is easy to reproduce,
and goes away when EXT*2*_PREALLOC is undefined.  Haven't looked
into it further, but I suppose one should.  It's not nice having
unexplained mysteries in ext2.

> How have you done the ext3 preallocation code?  One way to do it would be
> to only mark the blocks as used in the in-memory copy of the block bitmap
> and not write that to disk (we keep 2 copies of the block bitmap, IIRC).
> That way you don't need to do anything fancy at recovery time.
> 
> Did you ever benchmark ext2 with and without preallocation to see if it
> made any difference?  No point in doing extra work if there is no benefit.

This is an excellent point - it would be unwise to go to the
effort and complexity of putting prealloc back into ext3
without first analysing how useful it actually is.  Perhaps
some tuning of the other anti-fragmentation algorithms
will suffice.

For example, when we miss the goal block we search forward
up to 63 blocks for a *single* free block, and use that.
Perhaps we shouldn't?

And perhaps the search for eight contiguous free blocks
is no longer appropriate to current disks.  32 may be better?

So I'd prefer to set up a simulator and at least validate the
current algorithms beforehand, perhaps tune them as well.