search for: lookup_extent_map

...} while (1) { - if (!split) + if (!split) { split = alloc_extent_map(GFP_NOFS); - if (!split2) + BUG_ON(!split || IS_ERR(split)); + } + if (!split2) { split2 = alloc_extent_map(GFP_NOFS); + BUG_ON(!split2 || IS_ERR(split2)); + } write_lock(&em_tree->lock); em = lookup_extent_mapping(em_tree, start, len); diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index c9bc0af..40bbe00 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -287,6 +287,7 @@ static noinline int add_async_extent(struct async_cow *cow, struct async_extent *async_extent; async_extent = kmalloc(size...

...&& !(rw & (1 << BIO_RW))) - stripes_allocated = 1; -again: - if (multi_ret) { - multi = kzalloc(btrfs_multi_bio_size(stripes_allocated), - GFP_NOFS); - if (!multi) - return -ENOMEM; - - atomic_set(&multi->error, 0); - } - read_lock(&em_tree->lock); em = lookup_extent_mapping(em_tree, logical, *length); read_unlock(&em_tree->lock); @@ -2663,27 +2649,6 @@ again: map = (struct map_lookup *)em->bdev; offset = logical - em->start; - if (mirror_num > map->num_stripes) - mirror_num = 0; - - /* if our multi bio struct is too small, back off and...

rb_node cannot be an ERR_PTR() here so I removed the misleading check. Also I removed some more dead code at the bottom. It looks like the code from lookup_extent_mapping() may have been copy and pasted into search_extent_mapping()? Signed-off-by: Dan Carpenter <error27@gmail.com> --- This doesn''t change anything. Could you put it into linux-next? diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c index 94668b1..010f299 100644 --- a/fs...

...antic patching is available at http://coccinelle.lip6.fr/ Signed-off-by: Chris Samuel <chris@csamuel.org> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c index 454ca52..23cb8da 100644 --- a/fs/btrfs/extent_map.c +++ b/fs/btrfs/extent_map.c @@ -335,7 +335,7 @@ struct extent_map *lookup_extent_mapping(struct extent_map_tree *tree, goto out; } if (IS_ERR(rb_node)) { - em = ERR_PTR(PTR_ERR(rb_node)); + em = ERR_CAST(rb_node); goto out; } em = rb_entry(rb_node, struct extent_map, rb_node); @@ -384,7 +384,7 @@ struct extent_map *search_extent_mapping(struct extent_map_tree *tree,...

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

On 06/21/2011 01:15 PM, Jan Stilow wrote: > Hello, > > Nirbheek Chauhan <nirbheek <at> gentoo.org> writes: >> [...] >> >> Every few minutes, (I guess) when applications do fsync (firefox, >> xchat, vim, etc), all applications that use fsync() hang for several >> seconds, and applications that use general IO suffer extreme >> slowdowns.

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 17 Feb 2011 13:20:20 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=29302 > > Summary: Null pointer dereference with large max_sectors_kb > Product: IO/Storage > Version: 2.5 > Kernel

The biggest one is a fix for fstrim, and there''s a fix for on-disk free space cache. Others are small fixes and cleanups. The last three have been sent weeks ago. The patchset is also available in this repo: git://repo.or.cz/linux-btrfs-devel.git for-chris Note there''s a small confict with Al Viro''s vfs changes. Li Zefan (11): Btrfs: add pinned extents to

Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux May 5 14:15:12 mail kernel: [13559.089713] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 14:15:12 mail kernel: [13559.089834] parent transid verify failed on 3062073683968 wanted 5181 found 5188

...? kmsg_dump+0xcb/0xda Jun 10 14:50:23 mithrandir kernel: [40871.732005] [<ffffffff8100492e>] oops_end+0x89/0x8e Jun 10 14:50:23 mithrandir kernel: [40871.732005] [<ffffffff81396a4c>] no_context+0x1fe/0x20d Jun 10 14:50:23 mithrandir kernel: [40871.732005] [<ffffffffa0d9397f>] ? lookup_extent_mapping+0xaf/0xc2 [btrfs] Jun 10 14:50:23 mithrandir kernel: [40871.732005] [<ffffffff81396be9>] __bad_area_nosemaphore+0x18e/0x1b1 Jun 10 14:50:23 mithrandir kernel: [40871.732005] [<ffffffff81396c1a>] bad_area_nosemaphore+0xe/0x10 Jun 10 14:50:23 mithrandir kernel: [40871.732005] [<...

This series adds an initial implementation for scrub. It works quite straightforward. The usermode issues an ioctl for each device in the fs. For each device, it enumerates the allocated device chunks. For each chunk, the contained extents are enumerated and the data checksums fetched. The extents are read sequentially and the checksums verified. If an error occurs (checksum or EIO), a good copy

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

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