search for: submit_one_bio

...int rw, st if (bio_ret && *bio_ret) { bio = *bio_ret; + BUG_ON(!bio); if (bio->bi_sector + (bio->bi_size >> 9) != sector || bio_add_page(bio, page, size, offset) < size) { ret = submit_one_bio(rw, bio); @@ -1741,6 +1742,7 @@ static int submit_extent_page(int rw, st bio = extent_bio_alloc(bdev, sector, nr, GFP_NOFS | __GFP_HIGH); if (!bio) { printk("failed to allocate bio nr %d\n", nr); + BUG_ON(!bio); } -- Regards, Pete...

...24 22:44:54 minerva kernel: [ 1532.886665] [btrfs:btrfs_wq_submit_bio+0xbe/0xf0] :btrfs:btrfs_wq_submit_bio+0xbe/0xf0 Jul 24 22:44:54 minerva kernel: [ 1532.886743] [btrfs:__btree_submit_bio_hook+0x0/0x60] :btrfs:__btree_submit_bio_hook+0x0/0x60 Jul 24 22:44:54 minerva kernel: [ 1532.886826] [btrfs:submit_one_bio+0xcf/0x120] :btrfs:submit_one_bio+0xcf/0x120 Jul 24 22:44:54 minerva kernel: [ 1532.886907] [btrfs:extent_write_full_page+0x9d/0xb0] :btrfs:extent_write_full_page+0x9d/0xb0 Jul 24 22:44:54 minerva kernel: [ 1532.886992] [btrfs:btree_get_extent+0x0/0x1f0] :btrfs:btree_get_extent+0x0/0x1f0 Jul 24 22:...

A user has encountered a NULL pointer kernel oops in btrfs when encountering media errors. The problem has been identified as an unhandled NULL pointer returned from find_get_page(). This modification simply checks for a NULL page, and returns with an error if found (the extent_range_uptodate() function returns 1 on errors). After testing this patch, the user reported that the error with the

...neric_make_request.part.50+0x74/0xb0 [<ffffffff812f0788>] generic_make_request+0x68/0x70 [<ffffffff812f0815>] submit_bio+0x85/0x110 [<ffffffffa034ace5>] btrfs_map_bio+0x165/0x2f0 [btrfs] [<ffffffffa032880f>] btrfs_submit_bio_hook+0x7f/0x170 [btrfs] [<ffffffffa033b7da>] submit_one_bio+0x6a/0xa0 [btrfs] [<ffffffffa033f8a4>] submit_extent_page.isra.34+0xe4/0x230 [btrfs] [<ffffffffa034084c>] __extent_writepage+0x5ec/0x810 [btrfs] [<ffffffffa0340d22>] extent_write_cache_pages.isra.26.constprop.40+0x2b2/0x410 [btrfs] [<ffffffffa03410c5>] extent_writepages+0x45...

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

...fs at Aug 3 05:09:33 ... kernel: [<e0dae650>] ? btree_submit_bio_hook+0x15/0x3b [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dae63b>] ? btree_submit_bio_hook+0x0/0x3b [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dc0fc2>] ? submit_one_bio+0xdf/0x10c [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dc3854>] ? read_extent_buffer_pages+0x276/0x3c6 [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dc16cd>] ? add_lru+0x22/0x69 [btrfs] Message from syslogd@btrfs at Aug 3 05:09:3...

...prefetchw(&page->flags); + __extent_read_full_page(tree, page, get_extent, + &bio, 0, &bio_flags); + + page_cache_release(page); + list_del(&pagelst->lst); + kfree(pagelst); + } + BUG_ON(!list_empty(&page_pool)); BUG_ON(!list_empty(pages)); if (bio) return submit_one_bio(READ, bio, 0, bio_flags); -- 1.6.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

...prefetchw(&page->flags); + __extent_read_full_page(tree, page, get_extent, + &bio, 0, &bio_flags); + + page_cache_release(page); + list_del(&pagelst->lst); + kfree(pagelst); + } + BUG_ON(!list_empty(&page_pool)); BUG_ON(!list_empty(pages)); if (bio) return submit_one_bio(READ, bio, 0, bio_flags); -- 1.6.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

While testing raid-auto-repair patches I''m going to send out later, I just found the very last bug in my current scrub patch series: Changelog v4->v5: - fixed a deadlock when fixup is taking longer while scrub is about to end Original message follows: ------------------------ This patch set introduces two new features for scrub. They share the backref iteration code which is the

Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the

...Call Trace: Apr 30 14:25:46 btrfs kernel: [ 693.418782] [<ffffffff882e7341>] :btrfs:btrfs_map_block+0x11/0x20 Apr 30 14:25:46 btrfs kernel: [ 693.418863] [<ffffffff882e73a2>] :btrfs:btrfs_map_bio+0x52/0x180 Apr 30 14:25:46 btrfs kernel: [ 693.418946] [<ffffffff882e168f>] :btrfs:submit_one_bio+0xcf/0x120 Apr 30 14:25:46 btrfs kernel: [ 693.419029] [<ffffffff882e4d31>] :btrfs:read_extent_buffer_pages+0x2c1/0x3c0 Apr 30 14:25:46 btrfs kernel: [ 693.419111] [<ffffffff882cb900>] :btrfs:btree_get_extent+0x0/0x1d0 Apr 30 14:25:46 btrfs kernel: [ 693.419195] [<ffffffff882ca06d...

Hi, The following series of patches implements in btrfs an ioctl to do out-of-band deduplication of file extents. To be clear, this means that the file system is mounted and running, but the dedupe is not done during file writes, but after the fact when some userspace software initiates a dedupe. The primary patch is loosely based off of one sent by Josef Bacik back in January, 2011.

...io_flags || !contig || - merge_bio(tree, page, offset, page_size, bio, bio_flags) || - bio_add_page(bio, page, page_size, offset) < page_size) { + merge_bio(tree, page, offset, bio_size, bio, bio_flags) || + bio_add_page(bio, page, bio_size, offset) < bio_size) { ret = submit_one_bio(rw, bio, mirror_num, prev_bio_flags); if (ret < 0) @@ -2550,7 +2550,7 @@ static int submit_extent_page(int rw, struct extent_io_tree *tree, if (!bio) return -ENOMEM; - bio_add_page(bio, page, page_size, offset); + bio_add_page(bio, page, bio_size, offset); bio->bi_end_...

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

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

...t_read_full_page+0x4f7/0x7f0 [btrfs] [ 45.917188] [<f9ce1e79>] ? btrfs_bio_wq_end_io+0x29/0x70 [btrfs] [ 45.917188] [<f9ce20aa>] btree_submit_bio_hook+0x5a/0x100 [btrfs] [ 45.917188] [<f9ce2050>] ? btrfs_wq_submit_bio+0x170/0x170 [btrfs] [ 45.917188] [<f9d03c90>] submit_one_bio+0x80/0xb0 [btrfs] [ 45.917188] [<f9ce2050>] ? btrfs_wq_submit_bio+0x170/0x170 [btrfs] [ 45.917188] [<f9d0b848>] read_extent_buffer_pages+0x1f8/0x2b0 [btrfs] [ 45.917188] [<f9ce1af8>] btree_read_extent_buffer_pages.constprop.52+0xc8/0x140 [btrfs] [ 45.917188] [<f9cdf...

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