On Mon, 7 May 2007 05:37:54 -0600

Andreas Dilger  wrote:
> > > +	block = offset >> blkbits;

quoted text
> > > +	max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits) >> blkbits)

> > > +			 - block;

> > > +	mutex_lock(&EXT4_I(inode)->truncate_mutex);

> > > +	credits = ext4_ext_calc_credits_for_insert(inode, NULL);

> > > +	mutex_unlock(&EXT4_I(inode)->truncate_mutex);

> >

> > Now I'm mystified.  Given that we're allocating an arbitrary amount of disk

> > space, and that this disk space will require an arbitrary amount of

> > metadata, how can we work out how much journal space we'll be needing

> > without at least looking at `len'?

>

> Good question.

>

> The uninitialized extent can cover up to 128MB with a single entry.

> If @path isn't specified, then ext4_ext_calc_credits_for_insert()

> function returns the maximum number of extents needed to insert a leaf,

> including splitting all of the index blocks.  That would allow up to 43GB

> (340 extents/block * 128MB) to be preallocated, but it still needs to take

> the size of the preallocation into account (adding 3 blocks per 43GB - a

> leaf block, a bitmap block and a group descriptor).

I think the use of ext4_journal_extend() (as Amit has proposed) will help

here, but it is not sufficient.
Because under some circumstances, a journal_extend() failure could mean

that we fail to allocate all the required disk space.  If it is infrequent

enough, that is acceptable when the caller is using fallocate() for

performance reasons.
But it is very much not acceptable if the caller is using fallocate() for

space-reservation reasons.  If you used fallocate to reserve 1GB of disk

and fallocate() "succeeded" and you later get ENOSPC then you'd have a

right to get a bit upset.
So I think the ext3/4 fallocate() implementation will need to be

implemented as a loop: 
	while (len) {

		journal_start();

		len -= do_fallocate(len, ...);

		journal_stop();

	}
Now the interesting question is: what do we do if we get halfway through

this loop and then run out of space?  We could leave the disk all filled up

and then return failure to the caller, but that's pretty poor behaviour,

IMO.
Does the proposed implementation handle quotas correctly, btw?  Has that

been tested?
Final point: it's fairly disappointing that the present implementation is

ext4-only, and extent-only.  I do think we should be aiming at an ext4

bitmap-based implementation and an ext3 implementation.
-

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/