05 Jan, 2012

1 commit


22 Nov, 2011

1 commit


10 Sep, 2011

11 commits


28 Jun, 2011

1 commit

  • I found that ext4_ext_find_goal() and ext4_find_near()
    share the same code for returning a coloured start block
    based on i_block_group.

    We can refactor this into a common function so that they
    don't diverge in the future.

    Thanks to adilger for suggesting the new function name.

    Signed-off-by: Eric Sandeen
    Signed-off-by: "Theodore Ts'o"

    Eric Sandeen
     

25 May, 2011

1 commit

  • This patch adds an allocation request flag to the ext4_has_free_blocks
    function which enables the use of reserved blocks. This will allow a
    punch hole to proceed even if the disk is full. Punching a hole may
    require additional blocks to first split the extents.

    Because ext4_has_free_blocks is a low level function, the flag needs
    to be passed down through several functions listed below:

    ext4_ext_insert_extent
    ext4_ext_create_new_leaf
    ext4_ext_grow_indepth
    ext4_ext_split
    ext4_ext_new_meta_block
    ext4_mb_new_blocks
    ext4_claim_free_blocks
    ext4_has_free_blocks

    [ext4 punch hole patch series 1/5 v7]

    Signed-off-by: Allison Henderson
    Signed-off-by: "Theodore Ts'o"
    Reviewed-by: Mingming Cao

    Allison Henderson
     

09 May, 2011

1 commit


02 May, 2011

1 commit


31 Mar, 2011

1 commit


22 Mar, 2011

1 commit

  • - Add more ext4 tracepoints.
    - Change ext4 tracepoints to use dev_t field with MAJOR/MINOR macros
    so that we can save 4 bytes in the ring buffer on some platforms.
    - Add sync_mode to ext4_da_writepages, ext4_da_write_pages, and
    ext4_da_writepages_result tracepoints. Also remove for_reclaim
    field from ext4_da_writepages since it is usually not very useful.

    Signed-off-by: Jiaying Zhang
    Signed-off-by: "Theodore Ts'o"

    Jiaying Zhang
     

11 Jan, 2011

1 commit


28 Oct, 2010

2 commits


12 Jun, 2010

1 commit

  • We don't need to set s_dirt in most of the ext4 code when journaling
    is enabled. In ext3/4 some of the summary statistics for # of free
    inodes, blocks, and directories are calculated from the per-block
    group statistics when the file system is mounted or unmounted. As a
    result the superblock doesn't have to be updated, either via the
    journal or by setting s_dirt. There are a few exceptions, most
    notably when resizing the file system, where the superblock needs to
    be modified --- and in that case it should be done as a journalled
    operation if possible, and s_dirt set only in no-journal mode.

    This patch will optimize out some unneeded disk writes when using ext4
    with a journal.

    Signed-off-by: "Theodore Ts'o"

    Theodore Ts'o
     

16 May, 2010

1 commit

  • Because we can badly over-reserve metadata when we
    calculate worst-case, it complicates things for quota, since
    we must reserve and then claim later, retry on EDQUOT, etc.
    Quota is also a generally smaller pool than fs free blocks,
    so this over-reservation hurts more, and more often.

    I'm of the opinion that it's not the worst thing to allow
    metadata to push a user slightly over quota. This simplifies
    the code and avoids the false quota rejections that result
    from worst-case speculation.

    This patch stops the speculative quota-charging for
    worst-case metadata requirements, and just charges quota
    when the blocks are allocated at writeout. It also is
    able to remove the try-again loop on EDQUOT.

    This patch has been tested indirectly by running the xfstests
    suite with a hack to mount & enable quota prior to the test.

    I also did a more specific test of fragmenting freespace
    and then doing a large delalloc write under quota; quota
    stopped me at the right amount of file IO, and then the
    writeout generated enough metadata (due to the fragmentation)
    that it put me slightly over quota, as expected.

    Signed-off-by: Eric Sandeen
    Signed-off-by: "Theodore Ts'o"

    Eric Sandeen
     

04 Mar, 2010

2 commits

  • There are duplicate macro definitions of in_range() in mballoc.h and
    balloc.c. This consolidates these two definitions into ext4.h, and
    changes extents.c to use in_range() as well.

    Signed-off-by: Akinobu Mita
    Signed-off-by: "Theodore Ts'o"
    Cc: Andreas Dilger

    Akinobu Mita
     
  • This is a cleanup and simplification patch which takes some open-coded
    calculations to calculate the first block number of a group and
    converts them to use the (already defined) ext4_group_first_block_no()
    function.

    Signed-off-by: Akinobu Mita
    Signed-off-by: "Theodore Ts'o"
    Cc: Andreas Dilger

    Akinobu Mita
     

16 Feb, 2010

1 commit


23 Nov, 2009

1 commit


22 Nov, 2009

1 commit


18 Aug, 2009

1 commit

  • ext4_mb_update_group_info is only called in one place, and it's
    extremely simple. There's no reason to have it in a separate function
    in a separate file as far as I can tell, it just obfuscates what's
    really going on.

    Perhaps it was intended to keep the grp->bb_* manipulation local to
    mballoc.c but we're already accessing other grp-> fields in balloc.c
    directly so this seems ok.

    Signed-off-by: Eric Sandeen
    Signed-off-by: "Theodore Ts'o"

    Eric Sandeen
     

03 May, 2009

1 commit

  • We have sb_bgl_lock() and ext4_group_info.bb_state
    bit spinlock to protech group information. The later is only
    used within mballoc code. Consolidate them to use sb_bgl_lock().
    This makes the mballoc.c code much simpler and also avoid
    confusion with two locks protecting same info.

    Signed-off-by: Aneesh Kumar K.V
    Signed-off-by: "Theodore Ts'o"

    Aneesh Kumar K.V
     

02 May, 2009

1 commit


01 May, 2009

1 commit

  • Ext4's on-line resizing adds a new block group and then, only at the
    last step adjusts s_groups_count. However, it's possible on SMP
    systems that another CPU could see the updated the s_group_count and
    not see the newly initialized data structures for the just-added block
    group. For this reason, it's important to insert a SMP read barrier
    after reading s_groups_count and before reading any (for example) the
    new block group descriptors allowed by the increased value of
    s_groups_count.

    Unfortunately, we rather blatently violate this locking protocol
    documented in fs/ext4/resize.c. Fortunately, (1) on-line resizes
    happen relatively rarely, and (2) it seems rare that the filesystem
    code will immediately try to use just-added block group before any
    memory ordering issues resolve themselves. So apparently problems
    here are relatively hard to hit, since ext3 has been vulnerable to the
    same issue for years with no one apparently complaining.

    Signed-off-by: "Theodore Ts'o"

    Theodore Ts'o
     

26 Mar, 2009

1 commit


05 Mar, 2009

1 commit


26 Feb, 2009

1 commit


07 Feb, 2009

1 commit

  • The static function ext4_group_used_meta_blocks() only has one caller,
    who already has access to the block group's group descriptor. So it's
    better to have ext4_init_block_bitmap() pass the group descriptor to
    ext4_group_used_meta_blocks(), so it doesn't need to call
    ext4_group_desc(). Previously this function did not check if
    ext4_group_desc() returned NULL due to an error, potentially causing a
    kernel OOPS report. This avoids the issue entirely.

    Signed-off-by: Thadeu Lima de Souza Cascardo
    Signed-off-by: "Theodore Ts'o"

    Theodore Ts'o
     

27 Jan, 2009

1 commit

  • When bg_free_blocks_count was renamed to bg_free_blocks_count_lo in
    560671a0, its uses under EXT4FS_DEBUG were not changed to the helper
    ext4_free_blks_count.

    Another commit, 498e5f24, also did not change everything needed under
    EXT4FS_DEBUG, thus making it spill some warnings related to printing
    format.

    This commit fixes both issues and makes ext4 build again when
    EXT4FS_DEBUG is enabled.

    Signed-off-by: Thadeu Lima de Souza Cascardo
    Signed-off-by: "Theodore Ts'o"

    Thadeu Lima de Souza Cascardo
     

06 Jan, 2009

1 commit

  • For uninit block group, the on-disk bitmap is not initialized. That
    implies we cannot depend on the uptodate flag on the bitmap
    buffer_head to find bitmap validity. Use a new buffer_head flag which
    would be set after we properly initialize the bitmap. This also
    prevents (re-)initializing the uninit group bitmap every time we call
    ext4_read_block_bitmap().

    Signed-off-by: Aneesh Kumar K.V
    Signed-off-by: "Theodore Ts'o"
    Cc: stable@kernel.org

    Aneesh Kumar K.V
     

04 Jan, 2009

1 commit