linux-toradex.git/fs/btrfs/file-item.c, branch v3.10.2

btrfs: make static code static & remove dead code

2013-05-06T19:55:23+00:00

Big patch, but all it does is add statics to functions which
are in fact static, then remove the associated dead-code fallout.

removed functions:

btrfs_iref_to_path()
__btrfs_lookup_delayed_deletion_item()
__btrfs_search_delayed_insertion_item()
__btrfs_search_delayed_deletion_item()
find_eb_for_page()
btrfs_find_block_group()
range_straddles_pages()
extent_range_uptodate()
btrfs_file_extent_length()
btrfs_scrub_cancel_devid()
btrfs_start_transaction_lflush()

btrfs_print_tree() is left because it is used for debugging.
btrfs_start_transaction_lflush() and btrfs_reada_detach() are
left for symmetry.

ulist.c functions are left, another patch will take care of those.

Signed-off-by: Eric Sandeen 
Signed-off-by: Josef Bacik

Btrfs: remove unused argument of btrfs_extend_item()

2013-05-06T19:54:53+00:00

Argument 'trans' is not used in btrfs_extend_item().

Signed-off-by: Tsutomu Itoh 
Signed-off-by: Josef Bacik

Btrfs: cleanup of function where fixup_low_keys() is called

2013-05-06T19:54:52+00:00

If argument 'trans' is unnecessary in the function where
fixup_low_keys() is called, 'trans' is deleted.

Signed-off-by: Tsutomu Itoh 
Signed-off-by: Josef Bacik

Btrfs: improve the performance of the csums lookup

2013-05-06T19:54:35+00:00

It is very likely that there are several blocks in bio, it is very
inefficient if we get their csums one by one. This patch improves
this problem by getting the csums in batch.

According to the result of the following test, the execute time of
__btrfs_lookup_bio_sums() is down by ~28%(300us -> 217us).

 # dd if=/file of=/dev/null bs=1M count=1024

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik

btrfs: Cleanup some redundant codes in btrfs_lookup_csums_range()

2013-05-06T19:54:20+00:00

Signed-off-by: Zhi Yong Wu 
Signed-off-by: Josef Bacik

Btrfs: cleanup unused arguments of btrfs_csum_data

2013-05-06T19:54:14+00:00

Argument 'root' is no more used in btrfs_csum_data().

Signed-off-by: Liu Bo 
Signed-off-by: Josef Bacik

Btrfs: fix wrong return value of btrfs_lookup_csum()

2013-03-28T13:51:31+00:00

If we don't find the expected csum item, but find a csum item which is
adjacent to the specified extent, we should return -EFBIG, or we should
return -ENOENT. But btrfs_lookup_csum() return -EFBIG even the csum item
is not adjacent to the specified extent. Fix it.

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik

Btrfs: fix wrong reservation of csums

2013-03-28T13:51:30+00:00

We reserve the space for csums only when we write data into a file, in
the other cases, such as tree log, log replay, we don't do reservation,
so we can use the reservation of the transaction handle just for the former.
And for the latter, we should use the tree's own reservation. But the
function - btrfs_csum_file_blocks() didn't differentiate between these
two types of the cases, fix it.

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik

Btrfs: extend the checksum item as much as possible

2013-02-20T17:59:37+00:00

For write, we also reserve some space for COW blocks during updating
the checksum tree, and we calculate the number of blocks by checking
if the number of bytes outstanding that are going to need csums needs
one more block for csum.

When we add these checksum into the checksum tree, we use ordered sums
list.
Every ordered sum contains csums for each sector, and we'll first try
to look up an existing csum item,
a) if we don't yet have a proper csum item, then we need to insert one,
b) or if we find one but the csum item is not big enough, then we need
to extend it.

The point is we'll unlock the whole path and then insert or extend.
So others can hack in and update the tree.

Each insert or extend needs update the tree with COW on, and we may need
to insert/extend for many times.

That means what we've reserved for updating checksum tree is NOT enough
indeed.

The case is even more serious with having several write threads at the
same time, it can end up eating our reserved space quickly and starting
eating globle reserve pool instead.

I don't yet come up with a way to calculate the worse case for updating
csum, but extending the checksum item as much as possible can be helpful
in my test.

The idea behind is that it can reduce the times we insert/extend so that
it saves us precious reserved space.

Signed-off-by: Liu Bo 
Signed-off-by: Josef Bacik

Btrfs: put csums on the right ordered extent

2013-01-24T17:51:22+00:00

I noticed a WARN_ON going off when adding csums because we were going over
the amount of csum bytes that should have been allowed for an ordered
extent.  This is a leftover from when we used to hold the csums privately
for direct io, but now we use the normal ordered sum stuff so we need to
make sure and check if we've moved on to another extent so that the csums
are added to the right extent.  Without this we could end up with csums for
bytenrs that don't have extents to cover them yet.  Thanks,

Signed-off-by: Josef Bacik