1. 01 12月, 2008 1 次提交
    • E
      [XFS] convert xfs_getbmap to take formatter functions · 8a7141a8
      Eric Sandeen 提交于
      Preliminary work to hook up fiemap, this allows us to pass in an
      arbitrary formatter to copy extent data back to userspace.
      
      The formatter takes info for 1 extent, a pointer to the user "thing*"
      and a pointer to a "filled" variable to indicate whether a userspace
      buffer did get filled in (for fiemap, hole "extents" are skipped).
      
      I'm just using the getbmapx struct as a "common denominator" because
      as far as I can see, it holds all info that any formatters will care
      about.
      
      ("*thing" because fiemap doesn't pass the user pointer around, but rather
      has a pointer to a fiemap info structure, and helpers associated with it)
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NNiv Sardi <xaiki@sgi.com>
      8a7141a8
  2. 30 10月, 2008 1 次提交
  3. 28 7月, 2008 1 次提交
    • L
      [XFS] Restore the lowspace extent allocator algorithm · b877e3d3
      Lachlan McIlroy 提交于
      When free space is running low the extent allocator may choose to allocate
      an extent from an AG without leaving sufficient space for a btree split
      when inserting the new extent (see where xfs_bmap_btalloc() sets minleft
      to 0). In this case the allocator will enable the lowspace algorithm which
      is supposed to allow further allocations (such as btree splits and
      newroots) to allocate from sequential AGs. This algorithm has been broken
      for a long time and this patch restores its behaviour.
      
      SGI-PV: 983338
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31358a
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      b877e3d3
  4. 18 4月, 2008 1 次提交
  5. 07 2月, 2008 1 次提交
  6. 15 10月, 2007 2 次提交
  7. 14 7月, 2007 1 次提交
  8. 10 2月, 2007 1 次提交
  9. 09 6月, 2006 1 次提交
  10. 31 3月, 2006 1 次提交
  11. 29 3月, 2006 1 次提交
  12. 14 3月, 2006 2 次提交
    • M
      [XFS] 929045 567344 This mod introduces multi-level in-core file extent · 0293ce3a
      Mandy Kirkconnell 提交于
      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: NMandy Kirkconnell <alkirkco@sgi.com>
      Signed-off-by: NNathan Scott <nathans@sgi.com>
      0293ce3a
    • M
      [XFS] 929045 567344 This mod re-organizes some of the in-core file extent · 4eea22f0
      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: NMandy Kirkconnell <alkirkco@sgi.com>
      Signed-off-by: NNathan Scott <nathans@sgi.com>
      4eea22f0
  13. 11 1月, 2006 1 次提交
  14. 02 11月, 2005 3 次提交
  15. 21 6月, 2005 1 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4