[lkml]   [2007]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 4/5] ext4: fallocate support in ext4
    On Mon, 7 May 2007 05:37:54 -0600
    Andreas Dilger <> wrote:

    > > > + block = offset >> blkbits;
    > > > + 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) {
    len -= do_fallocate(len, ...);

    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,

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-07 23:01    [W:0.025 / U:67.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site