search for: btrfs_merge_bio_hook

...ret; iocount++; block_start = block_start + iosize; } else { Index: linux-2.6.35-rc2-gcc/fs/btrfs/inode.c =================================================================== --- linux-2.6.35-rc2-gcc.orig/fs/btrfs/inode.c +++ linux-2.6.35-rc2-gcc/fs/btrfs/inode.c @@ -1372,7 +1372,7 @@ int btrfs_merge_bio_hook(struct page *pa if (map_length < length + size) return 1; - return 0; + return ret; } /* @@ -2672,7 +2672,7 @@ static int check_path_shared(struct btrf { struct extent_buffer *eb; int level; - int ret; + int ret = 0; u64 refs; for (level = 0; level < BTRFS_MAX_LEVEL; lev...

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

If we have particularly full nodes, we could call btrfs_node_blockptr up to 32 times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the extent buffer while we look for readahead targets. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git

This series introduces a generic readahead interface for btrfs trees. The intention is to use it to speed up scrub in a first run, but balance is another hot candidate. In general, every tree walk could be accompanied by a readahead. Deletion of large files comes to mind, where the fetching of the csums takes most of the time. Also the initial build-ups of free-space-caches and

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

This series introduces a generic readahead interface for btrfs trees. The intention is to use it to speed up scrub in a first run, but balance is another hot candidate. In general, every tree walk could be accompanied by a readahead. Deletion of large files comes to mind, where the fetching of the csums takes most of the time. Also the initial build-ups of free-space-caches and

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them