search for: io_tree

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

...ip all + * those expensive operations on a per page basis and do only the ordered io + * finishing, while we release here the extent_map and extent_state structures, + * without the excessive merging and splitting. + */ +static void evict_inode_truncate_pages(struct inode *inode) +{ + struct extent_io_tree *io_tree = &BTRFS_I(inode)->io_tree; + struct extent_map_tree *map_tree = &BTRFS_I(inode)->extent_tree; + struct rb_node *node; + + ASSERT(inode->i_state & I_FREEING); + truncate_inode_pages(&inode->i_data, 0); + + write_lock(&map_tree->lock); + while (!RB_EMPTY_R...

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

...fy that we have locked everything we need to do the read and + * have pushed the ordered data into the btree so the extent is valid + */ +static void btrfs_dio_safe_to_read(struct btrfs_diocb *diocb, + struct extent_map *em, u64 *lockend, + u64 *data_len, int *safe_to_read) +{ + struct extent_io_tree *io_tree = &BTRFS_I(diocb->inode)->io_tree; + struct btrfs_ordered_extent *ordered; + u64 stop; + + /* must ensure the whole compressed extent is valid on each loop + * as we don''t know the final extent size until we look it up + */ + if (test_bit(EXTENT_FLAG_COMPRESSED, &e...

...- a/src/event.c +++ b/src/event.c @@ -387,71 +389,89 @@ bool event_loop(void) { Note that technically FD_CLOSE has the same problem, but it's okay because user code does not rely on this event being fired again if ignored. */ - io_t *writeable_io = NULL; + unsigned int curgen = io_tree.generation; - for splay_each(io_t, io, &io_tree) + for splay_each(io_t, io, &io_tree) { if(io->flags & IO_WRITE && send(io->fd, NULL, 0, 0) == 0) { - writeable_io = io; - break; + io->cb(io->data, IO_WRITE); + + if(curgen != io_tree.generation) {...

...100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -794,7 +794,7 @@ int readahead_tree_block(struct btrfs_root *root, u64 bytenr, u32 blocksize, buf = btrfs_find_create_tree_block(root, bytenr, blocksize); if (!buf) return 0; - read_extent_buffer_pages(&BTRFS_I(btree_inode)->io_tree, + ret = read_extent_buffer_pages(&BTRFS_I(btree_inode)->io_tree, buf, 0, 0, btree_get_extent, 0); free_extent_buffer(buf); return ret; -- 1.6.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kerne...

Just a quick update, I''ve dropped the hashing stuff in favor of doing a memcmp in the kernel to make sure the data is still the same. The thing that takes a while is reading the data up from disk, so doing a memcmp of the entire buffer isn''t that big of a deal, not to mention there''s a possiblity for malicious users if there is a problem with the hashing algorithms we

...------ fs/btrfs/ioctl.c | 8 ++++---- 5 files changed, 28 insertions(+), 14 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 4c87847..604e404 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -1144,6 +1144,14 @@ int set_extent_delalloc(struct extent_io_tree *tree, u64 start, u64 end, NULL, cached_state, mask); } +int set_extent_defrag(struct extent_io_tree *tree, u64 start, u64 end, + struct extent_state **cached_state, gfp_t mask) +{ + return set_extent_bit(tree, start, end, + EXTENT_DELALLOC | EXTENT_UPTODATE | EXTENT_DEF...

On Mon, 26 Feb 2018 23:01:29 +0100, Guus Sliepen wrote: > The problem is not the order of the events, the problem is that in the > Windows version of the event loop, we only handle one event in each loop > iteration. The select() loop handles all events that have accumulated so > far, so regardless of the order it handles them, it never starves fd. At > least, that was what I

.../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; lock_extent(&BTRFS_I(inode)->io_tree, 0, len, GFP_NOFS); ordered = btrfs_lookup_first_ordered_extent(inode, len); if (BTRFS_I(inode)->delalloc_bytes == 0 && !ordered) break; unlock_extent(&BTRFS_I(inode)->io_tree, 0, len, GFP_NOFS); if (ordered) btrfs_put_ordered_extent(ordered); btrfs_wait_ordered_ra...

...num_bytes, num_bytes, type); BUG_ON(ret); + if (root->root_key.objectid == + BTRFS_DATA_RELOC_TREE_OBJECTID) { + ret = btrfs_reloc_clone_csums(inode, cur_offset, + num_bytes); + BUG_ON(ret); + } + extent_clear_unlock_delalloc(inode, &BTRFS_I(inode)->io_tree, cur_offset, cur_offset + num_bytes - 1, locked_page, EXTENT_CLEAR_UNLOCK_PAGE | @@ -6079,16 +6086,15 @@ out_unlock: return err; } -static int prealloc_file_range(struct inode *inode, u64 start, u64 end, - u64 alloc_hint, int mode, loff_t actual_len) +int btrfs_prealloc_file_range(...

...82,7 +882,7 @@ static noinline int cow_file_range(struct inode *inode, */ op = unlock ? EXTENT_CLEAR_UNLOCK_PAGE : 0; op |= EXTENT_CLEAR_UNLOCK | EXTENT_CLEAR_DELALLOC | - EXTENT_SET_PRIVATE2; + EXTENT_SET_PRIVATE2; extent_clear_unlock_delalloc(inode, &BTRFS_I(inode)->io_tree, start, start + ram_size - 1, @@ -1778,6 +1778,9 @@ static int btrfs_finish_ordered_io(struct inode *inode, u64 start, u64 end) ordered_extent->len); BUG_ON(ret); } + clear_extent_bit(io_tree, ordered_extent->file_offset, + ordered_extent->file_offset + ordered_e...

...unsigned long ram_size; @@ -823,25 +823,10 @@ static noinline int cow_file_range(struct inode *inode, int ret = 0; BUG_ON(btrfs_is_free_space_inode(inode)); - trans = btrfs_join_transaction(root); - if (IS_ERR(trans)) { - extent_clear_unlock_delalloc(inode, - &BTRFS_I(inode)->io_tree, - start, end, locked_page, - EXTENT_CLEAR_UNLOCK_PAGE | - EXTENT_CLEAR_UNLOCK | - EXTENT_CLEAR_DELALLOC | - EXTENT_CLEAR_DIRTY | - EXTENT_SET_WRITEBACK | - EXTENT_END_WRITEBACK); - return PTR_ERR(trans); - } - trans->block_rsv = &root->fs...

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.

...Moving the most recently > accessed event to the end gives the others a chance to proceed. But it doesn't order them by most recently accessed. It's a deterministic order that doesn't change except when io_add() or io_del() is called. Or put in another way: splay_each(io_t, io, &io_tree) goes through the nodes of the io_tree in the order determined by io_compare(). -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-sig...

...> > accessed event to the end gives the others a chance to proceed. > > But it doesn't order them by most recently accessed. It's a > deterministic order that doesn't change except when io_add() or io_del() > is called. Or put in another way: splay_each(io_t, io, &io_tree) goes > through the nodes of the io_tree in the order determined by > io_compare(). Unlike the POSIX event code, the Windows version calls splay_search() to map the event to an io_t. The call to splay_search() will splay the tree which changes the order the next time we go through the loop....

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

...ine && start <= key.offset) - keep = 1; + search_start = max(key.offset, start); + if (recow) { + btrfs_release_path(root, path); + continue; } - if (bookend && found_extent) { - if (locked_end < extent_end) { - ret = try_lock_extent(&BTRFS_I(inode)->io_tree, - locked_end, extent_end - 1, - GFP_NOFS); - if (!ret) { - btrfs_release_path(root, path); - lock_extent(&BTRFS_I(inode)->io_tree, - locked_end, extent_end - 1, - GFP_NOFS); - locked_end = extent_end; - continue; - } - locked_end = extent_end; +...

...node)->root, 1); - if (!trans) { - ret = -EIO; - goto out_free; - } - /* the extent lock is ordered inside the running * transaction */ @@ -5691,8 +5745,6 @@ static long btrfs_fallocate(struct inode btrfs_put_ordered_extent(ordered); unlock_extent(&BTRFS_I(inode)->io_tree, alloc_start, locked_end, GFP_NOFS); - btrfs_end_transaction(trans, BTRFS_I(inode)->root); - /* * we can''t wait on the range with the transaction * running or with the extent lock held @@ -5713,9 +5765,12 @@ static long btrfs_fallocate(struct inode BUG_ON(I...

...ertions(+), 0 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index da4457f..4c86711 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -961,6 +961,13 @@ static int btree_releasepage(struct page *page, gfp_t gfp_flags) tree = &BTRFS_I(page->mapping->host)->io_tree; map = &BTRFS_I(page->mapping->host)->extent_tree; + /* + * We need to mask out eg. __GFP_HIGHMEM and __GFP_DMA32 as we''re doing + * slab allocation from alloc_extent_state down the callchain where + * it''d hit a BUG_ON as those flags are not allowed. + */ + g...