search for: btrfs_get_extent

I''m going to be removing hole extents in the near future so I wanted to make a sanity test for btrfs_get_extent to make sure I don''t break anything in the meantime. This patch just puts btrfs_get_extent through its paces by giving it a completely unreasonable mapping to look at and make sure it is giving us back maps that make sense. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>...

We''ve been hitting BUG()''s in btrfs_cont_expand and btrfs_fallocate and anywhere else that calls btrfs_get_extent while running xfstests 13 in a loop. This is because fiemap is calling btrfs_get_extent with non-sectorsize aligned offsets, which will end up adding mappings that are not sectorsize aligned, which will cause problems in some cases for subsequent calls to btrfs_get_extent for similar areas that ar...

Returns a file''s size on disk. Had been posted by Chris Ball over a year ago (http://article.gmane.org/gmane.comp.file-systems.btrfs/2873). Chris Mason suggested a couple of improvements back then, which I have implemented in this version: - use u64 to return the result - replaced the loop while (1) { struct btrfs_ordered_extent *ordered;

...ents/btrfs.h | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h index f18b3b7..4fbe10a 100644 --- a/include/trace/events/btrfs.h +++ b/include/trace/events/btrfs.h @@ -206,17 +206,17 @@ TRACE_EVENT(btrfs_get_extent, __entry->refs, __entry->compress_type) ); -#define show_ordered_flags(flags) \ - __print_symbolic(flags, \ - { BTRFS_ORDERED_IO_DONE, "IO_DONE" }, \ - { BTRFS_ORDERED_COMPLETE, "COMPLETE" }, \ - { BTRFS_ORDERED_NOCOW, "NOCOW" }, \ - {...

...ba69ed>] ? __extent_writepage+0x1a0/0x62d [btrfs] [<c0456f41>] ? write_cache_pages+0x180/0x287 [<f8ba684d>] ? __extent_writepage+0x0/0x62d [btrfs] [<f8b9b079>] ? btrfs_writepages+0x0/0x1d [btrfs] [<f8ba53c6>] ? extent_writepages+0x29/0x44 [btrfs] [<f8b9d029>] ? btrfs_get_extent+0x0/0x70e [btrfs] [<f8b9b091>] ? btrfs_writepages+0x18/0x1d [btrfs] [<c0457092>] ? do_writepages+0x23/0x34 [<c0487ee2>] ? __writeback_single_inode+0x123/0x22a [<c0488317>] ? sync_sb_inodes+0x192/0x249 [<c04886b0>] ? writeback_inodes+0x6a/0xb1 [<c0457b89>] ?...

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

...rrupt+0xe/0x13 Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa043417b>] extent_writepages+0x3f/0x50 [btrfs] Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113e27a>] ? list_move+0x29/0x30 Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa041af1d>] ? btrfs_get_extent+0x0/0x74f [btrfs] Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa041ade3>] btrfs_writepages+0x28/0x2a [btrfs] Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810e05d5>] do_writepages+0x21/0x2a Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113e386>...

...t, but if it''s not it will mean we screw up O_DIRECT on snapshotted files with preallocated extents, so please, make sure it is correct :). --- Subject: [PATCH] Btrfs: rework can_nocow_odirect We are always doing the file extent lookup in here even though we''ve already done the btrfs_get_extent which does the exact same thing. So re-work can_nocow_odirect to get the same information out of the extent_map we already have and then do the cross ref check and csum checks as appropriate. This reduces the number of allocations and searches we do for every O_DIRECT write and man it helps a lot....

...b->lockstart, lockend, GFP_NOFS); - mutex_unlock(&diocb->inode->i_mutex); - - data_len = end - diocb->start; + safe_to_read = 0; while (data_len && !diocb->error) { /* error in reaper stops submit */ struct extent_map *em; - u64 len = data_len; + u64 len; em = btrfs_get_extent(diocb->inode, NULL, 0, - diocb->start, len, 0); + diocb->start, data_len, 0); if (IS_ERR(em)) { err = PTR_ERR(em); printk(KERN_ERR @@ -496,6 +546,18 @@ getlock: goto fail; } + /* verify extent was locked and ordered data was flushed, + * may change data_len a...

I suspect this might be related to previous btrfs errors I''ve had on the same filesystem. See: http://python.ca/nas/linux/btrfs_bug.txt The most recent kernel message is: WARNING: at fs/btrfs/extent-tree.c:8239 btrfs_free_block_groups+0x218/0x275() Hardware name: MS-7388 Modules linked in: udf crc_itu_t isofs loop nls_iso8859_1 vboxnetflt vboxdrv nls_utf8 nls_cp437

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 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 Linus, My for-linus branch has a one line fix: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a regression in our initial rc1 pull. When doing nocow writes we were sometimes starting a transaction with locks held. Josef Bacik (1) commits (+1/-0): Btrfs: release path before starting

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.

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

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