currently xfs_bmbt_rec_t is used both for ondisk extents as well as
host-endian ones. This patch adds a new xfs_bmbt_rec_host_t for the native
endian ones and cleans up the fallout. There have been various endianess
issues in the tracing / debug printf code that are fixed by this patch.

SGI-PV: 968563
SGI-Modid: xfs-linux-melb:xfs-kern:29318a
Signed-off-by: NChristoph Hellwig <hch@infradead.org>
Signed-off-by: NDavid Chinner <dgc@sgi.com>
Signed-off-by: NTim Shimmin <tes@sgi.com>

Remove the hardcoded "fnames" for tracing, and just embed them in tracing
macros via __FUNCTION__. Kills a lot of #ifdefs too.

SGI-PV: 967353
SGI-Modid: xfs-linux-melb:xfs-kern:29099a
Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
Signed-off-by: NDavid Chinner <dgc@sgi.com>
Signed-off-by: NTim Shimmin <tes@sgi.com>

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: NEric Sandeen <sandeen@sandeen.net>
Signed-off-by: NDavid Chinner <dgc@sgi.com>
Signed-off-by: NTim Shimmin <tes@sgi.com>

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: NOlaf Weber <olaf@sgi.com>
Signed-off-by: NNathan Scott <nathans@sgi.com>

xfs_bmap_do_search_extents().

SGI-PV: 951415
SGI-Modid: xfs-linux-melb:xfs-kern:208491a
Signed-off-by: NMandy Kirkconnell <alkirkco@sgi.com>
Signed-off-by: NNathan Scott <nathans@sgi.com>

SGI-PV: 951415
SGI-Modid: xfs-linux-melb:xfs-kern:208490a
Signed-off-by: NMandy Kirkconnell <alkirkco@sgi.com>
Signed-off-by: NNathan Scott <nathans@sgi.com>

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>

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>

well.  Also provides a mechanism for inheriting this property from the
parent directory for new files.

SGI-PV: 945264
SGI-Modid: xfs-linux-melb:xfs-kern:24367a
Signed-off-by: NNathan Scott <nathans@sgi.com>

boilerplate.

SGI-PV: 913862
SGI-Modid: xfs-linux:xfs-kern:23903a
Signed-off-by: NNathan Scott <nathans@sgi.com>

SGI-PV: 943122
SGI-Modid: xfs-linux:xfs-kern:23901a
Signed-off-by: NNathan Scott <nathans@sgi.com>

the data/attr forks now grow up/down from either end of the literal area,
rather than dividing the literal area into two chunks and growing both
upward.  Means we can now make much more efficient use of the attribute
space, incl. fitting DMF attributes inline in 256 byte inodes, and large
jumps in dbench3 performance numbers.  It is self enabling, but can be
forced on/off via the attr2/noattr2 mount options.

SGI-PV: 941645
SGI-Modid: xfs-linux:xfs-kern:23835a
Signed-off-by: NNathan Scott <nathans@sgi.com>

SGI-PV: 936255
SGI-Modid: xfs-linux:xfs-kern:192760a
Signed-off-by: NChristoph Hellwig <hch@sgi.com>
Signed-off-by: NNathan Scott <nathans@sgi.com>

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!