10 Feb, 2007

1 commit

  • The firstblock argument to xfs_bmap_finish is not used by that function.
    Remove it and cleanup the code a bit.

    Patch provided by Eric Sandeen.

    SGI-PV: 960196
    SGI-Modid: xfs-linux-melb:xfs-kern:28034a

    Signed-off-by: Eric Sandeen
    Signed-off-by: David Chinner
    Signed-off-by: Tim Shimmin

    Eric Sandeen
     

09 Jun, 2006

1 commit

  • the range spanned by modifications to the in-core extent map. Add
    XFS_BUNMAPI() and XFS_SWAP_EXTENTS() macros that call xfs_bunmapi() and
    xfs_swap_extents() via the ioops vector. Change all calls that may modify
    the in-core extent map for the data fork to go through the ioops vector.
    This allows a cache of extent map data to be kept in sync.

    SGI-PV: 947615
    SGI-Modid: xfs-linux-melb:xfs-kern:209226a

    Signed-off-by: Olaf Weber
    Signed-off-by: Nathan Scott

    Olaf Weber
     

31 Mar, 2006

1 commit


29 Mar, 2006

1 commit


14 Mar, 2006

2 commits

  • functionality, building upon the new layout introduced in mod
    xfs-linux:xfs-kern:207390a. The new multi-level extent allocations are
    only required for heavily fragmented files, so the old-style linear extent
    list is used on files until the extents reach a pre-determined size of 4k.
    4k buffers are used because this is the system page size on Linux i386 and
    systems with larger page sizes don't seem to gain much, if anything, by
    using their native page size as the extent buffer size. Also, using 4k
    extent buffers everywhere provides a consistent interface for CXFS across
    different platforms. The 4k extent buffers are managed by an indirection
    array (xfs_ext_irec_t) which is basically just a pointer array with a bit
    of extra information to keep track of the number of extents in each buffer
    as well as the extent offset of each buffer. Major changes include: -
    Add multi-level in-core file extent functionality to the xfs_iext_
    subroutines introduced in mod: xfs-linux:xfs-kern:207390a - Introduce 13
    new subroutines which add functionality for multi-level in-core file
    extents: xfs_iext_add_indirect_multi()
    xfs_iext_remove_indirect() xfs_iext_realloc_indirect()
    xfs_iext_indirect_to_direct() xfs_iext_bno_to_irec()
    xfs_iext_idx_to_irec() xfs_iext_irec_init()
    xfs_iext_irec_new() xfs_iext_irec_remove()
    xfs_iext_irec_compact() xfs_iext_irec_compact_pages()
    xfs_iext_irec_compact_full() xfs_iext_irec_update_extoffs()

    SGI-PV: 928864
    SGI-Modid: xfs-linux-melb:xfs-kern:207393a

    Signed-off-by: Mandy Kirkconnell
    Signed-off-by: Nathan Scott

    Mandy Kirkconnell
     
  • code to prepare for an upcoming mod which will introduce multi-level
    in-core extent allocations. Although the in-core extent management is
    using a new code path in this mod, the functionality remains the same.
    Major changes include: - Introduce 10 new subroutines which re-orgainze
    the existing code but do NOT change functionality:
    xfs_iext_get_ext() xfs_iext_insert() xfs_iext_add()
    xfs_iext_remove() xfs_iext_remove_inline()
    xfs_iext_remove_direct() xfs_iext_realloc_direct()
    xfs_iext_direct_to_inline() xfs_iext_inline_to_direct()
    xfs_iext_destroy() - Remove 2 subroutines (functionality moved to new
    subroutines above): xfs_iext_realloc() -replaced by xfs_iext_add()
    and xfs_iext_remove() xfs_bmap_insert_exlist() - replaced by
    xfs_iext_insert() xfs_bmap_delete_exlist() - replaced by
    xfs_iext_remove() - Replace all hard-coded (indexed) extent assignments
    with a call to xfs_iext_get_ext() - Replace all extent record pointer
    arithmetic (ep++, ep--, base + lastx,..) with calls to
    xfs_iext_get_ext() - Update comments to remove the idea of a single
    "extent list" and introduce "extent record" terminology instead

    SGI-PV: 928864
    SGI-Modid: xfs-linux-melb:xfs-kern:207390a

    Signed-off-by: Mandy Kirkconnell
    Signed-off-by: Nathan Scott

    Mandy Kirkconnell
     

11 Jan, 2006

1 commit


02 Nov, 2005

3 commits


21 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds