Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

balance level starts by trying to empty the middle block, and then
pushes from the right to the middle.  This might empty the right block
and leave a small number of pointers in the middle.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

The generic O_DIRECT code assumes all the bios have the same bdev,
which isn't true for multi-device btrfs.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

This allows other code that needs to walk every device in the FS to do so
without locking against allocations.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

This properly reflects the first 1MB we skip at the start of the device
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

btrfs_invalidatepage is not allowed to leave pages around on the lru.
Any such pages will trigger an oops later on because the VM will see
page->private and assume it is a buffer head.

This also forces extra flushes of the async work queues before
dropping all the pages on the btree inode during unmount.  Left over
items on the work queues are one possible cause of busy state ranges
during truncate_inode_pages.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

The btree inode should only have a single extent_map in the cache,
it doesn't make sense to ever drop it.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

It was testing the bio before doing logical->physical mapping, so the
test was always wrong.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

The data read retry code needs to find the logical disk block before it
can resubmit new bios.  But, finding this block isn't allowed to take
the fs_mutex because that will deadlock with a number of different callers.

This changes the retry code to use the extent map cache instead, but
that requires the extent map cache to have the extent we're looking for.
This is a problem because btrfs_drop_extent_cache just drops the entire
extent instead of the little tiny part it is invalidating.

The bulk of the code in this patch changes btrfs_drop_extent_cache to
invalidate only a portion of the extent cache, and changes btrfs_get_extent
to deal with the results.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

This isn't required anymore because we don't reallocate blocks that
have already been written in this transaction.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

This significantly improves streaming write performance by allowing
concurrency in the data checksumming.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

This allows checksumming to happen in parallel among many cpus, and
keeps us from bogging down pdflush with the checksumming code.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Block headers now store the chunk tree uuid

Chunk items records the device uuid for each stripes

Device extent items record better back refs to the chunk tree

Block groups record better back refs to the chunk tree

The chunk tree format has also changed.  The objectid of BTRFS_CHUNK_ITEM_KEY
used to be the logical offset of the chunk.  Now it is a chunk tree id,
with the logical offset being stored in the offset field of the key.

This allows a single chunk tree to record multiple logical address spaces,
upping the number of bytes indexed by a chunk tree from 2^64 to
2^128.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

This includes fixing a missing spinlock init call that caused oops on mount
for most kernels other than 2.6.25.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

On huge machines, delayed allocation may try to allocate massive extents.
This change allows btrfs_alloc_extent to return something smaller than
the caller asked for, and the data allocation routines will loop over
the allocations until it fills the whole delayed alloc.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

bio_endio() changed prototype on linux 2.6.24, support older kernels
using the older prototype.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

write_cache_pages doesn't exist in linux 2.6.20,  change the #if
condition to match that.
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Fix for a endianess BUG when using btrfs v0.13 with kernels older than 2.6.23

Problem:

Has of v0.13, btrfs-progs is using crc32c.c equivalent to the one found on
linux-2.6.23/lib/libcrc32c.c Since crc32c_le() changed in linux-2.6.23, when
running btrfs v0.13 with older kernels we have a missmatch between the versions
of crc32c_le() from btrfs-progs and libcrc32c in the kernel.  This missmatch
causes a bug when using btrfs on big endian machines.

Solution:
btrfs_crc32c() macro that when compiling for kernels older than 2.6.23, does
endianess conversion to parameters and return value of crc32c().
This endianess conversion nullifies the differences in implementation
of crc32c_le().
If kernel 2.6.23 or better, it calls crc32c().
Signed-off-by: Miguel Sousa Filipe <miguel.filipe@gmail.com>
---
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Signed-off-by: Chris Mason <chris.mason@oracle.com>