search for: space_info

...fs_prepare_extent_commit(struct btrfs_trans_handle *trans, struct btrfs_root *root); int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans, @@ -2269,8 +2267,11 @@ void btrfs_put_block_group_cache(struct btrfs_fs_info *info); u64 btrfs_account_ro_block_groups_free_space(struct btrfs_space_info *sinfo); int btrfs_error_unpin_extent_range(struct btrfs_root *root, u64 start, u64 end); -int btrfs_error_discard_extent(struct btrfs_root *root, u64 bytenr, - u64 num_bytes, u64 *actual_bytes); +int btrfs_discard_extent(struct btrfs_root *root, u64 bytenr, u64 num_bytes, + u6...

...fs_prepare_extent_commit(struct btrfs_trans_handle *trans, struct btrfs_root *root); int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans, @@ -2269,8 +2267,11 @@ void btrfs_put_block_group_cache(struct btrfs_fs_info *info); u64 btrfs_account_ro_block_groups_free_space(struct btrfs_space_info *sinfo); int btrfs_error_unpin_extent_range(struct btrfs_root *root, u64 start, u64 end); -int btrfs_error_discard_extent(struct btrfs_root *root, u64 bytenr, - u64 num_bytes, u64 *actual_bytes); +int btrfs_discard_extent(struct btrfs_root *root, u64 bytenr, u64 num_bytes, + u6...

...tate machine into this, which will make it easier to get cache miss information out of the allocator, and will work well with my locking changes. The basic flow is this. We have the variable loop which is 0, meaning we are in the hint phase. We lookup the block group for the hint, and lookup the space_info for what we want to allocate out of. If the block group we were pointed at by the hint either isn''t of the correct type, or just doesn''t have the space we need, we set head to space_info->block_groups, so we start at the beginning of the block groups for this particular space...

The whole loop=0,1,2 thing was kind of odd and not very self explanatory. I''ve replaced it with a list_for_each_entry on space_info->block_groups. If we have a hint we just jump into the loop with the block group and start looking for space. If we don''t find anything we start at the beginning and start looking. We never come out of the loop with a ref on the block_group _unless_ we found space to use, then we drop...

...d_super+0x21/0x41 [<ffffffff810abba6>] deactivate_super+0x40/0x44 [<ffffffff810bfcfe>] mntput_no_expire+0xdd/0x10b [<ffffffff810c0276>] sys_umount+0x2d2/0x2fd [<ffffffff810028bb>] system_call_fastpath+0x16/0x1b ---[ end trace 3f9c8cf600895a9f ]--- space_info has 1751910400 free, is not full space_info total=5377097728, used=3611955200, pinned=0, reserved=4843520, may_use=0, readonly=8388608 The code is: while(!list_empty(&info->space_info)) { space_info = list_entry(info->space_info.next, struct btrfs_spa...

...tent tree, checksum tree and root tree Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 8/fs/btrfs/ctree.h 9/fs/btrfs/ctree.h --- 8/fs/btrfs/ctree.h 2010-04-18 10:26:38.327697818 +0800 +++ 9/fs/btrfs/ctree.h 2010-04-18 10:30:01.883697869 +0800 @@ -682,21 +682,15 @@ struct btrfs_space_info { u64 bytes_reserved; /* total bytes the allocator has reserved for current allocations */ u64 bytes_readonly; /* total bytes that are read only */ - u64 bytes_super; /* total bytes reserved for the super blocks */ - u64 bytes_root; /* the number of bytes needed to commit a - tra...

...FLUSH_DELALLOC (1)'' for 1024 retries. This reduces and/or eliminates the ENOSPC errors, as if we''re waiting on something else that is trying to complete. (5) I''ve been heavily debugging the reserve_metadata_bytes() function, and I''m seeing problems with the way space_info->bytes_may_use is handled. The space_info->bytes_may_use value is important in determining if we''re in an over-commit state. But space_info->bytes_may_use value is often increased arbitrarily without any mechanism for correcting the value. Subsequently, space_info->bytes_may_...

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

In clear_extent_bit, it is enough that next node is adjacent in tree level. Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> --- fs/btrfs/extent_io.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index fcf77e1..e941cc4 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -577,8 +577,7 @@ hit_next: if

Hi, my system suddenly crashed and gave me this dump: http://imgur.com/oO6S0 I checked and there is not btrfs commit in linus'' tree since I compiled this kernel. Gustavo

...ling for btrfs. Now whenever you do a btrfs_start_transaction, you must specify the number of items you are planning to add/delete/modify. The worst case number of blocks that could be modified by changing that number of items will be calculated and checked against the amount of free space in the space_info where the root you are modifying would allocate out of. If there is not enough free space, you will get an PTR_ERR(-ENOSPC) returned. Now the data ENOSPC checker does not check metadata space, it only checks data space, and this seems to speed up my fs_mark tests quite a bit. Everytime we start...

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

.../btrfs/extent-tree.c 2010-05-11 14:15:29.174108554 +0800 +++ 8/fs/btrfs/extent-tree.c 2010-05-11 13:26:38.036107000 +0800 @@ -316,11 +329,6 @@ static int caching_kthread(void *data) if (!path) return -ENOMEM; - exclude_super_stripes(extent_root, block_group); - spin_lock(&block_group->space_info->lock); - block_group->space_info->bytes_super += block_group->bytes_super; - spin_unlock(&block_group->space_info->lock); - last = max_t(u64, block_group->key.objectid, BTRFS_SUPER_INFO_OFFSET); /* @@ -7499,6 +7541,7 @@ int btrfs_free_block_groups(struct btrfs if...

This reverts commit 5500cdbe14d7435e04f66ff3cfb8ecd8b8e44ebf. We had numerous reports of premature ENOSPC that were bisected to this patch. Reverting will not break things but a warning in ''use_block_rsv'' may show up in the syslog. There''s no alternative fix in sight and the ENOSPC problem affects all 3.3 btrfs users during normal filesystem use. CC:

...tent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4004,7 +4004,7 @@ again: * We make the other tasks wait for the flush only when we can flush * all things. */ - if (ret && flush == BTRFS_RESERVE_FLUSH_ALL) { + if (ret && flush != BTRFS_RESERVE_NO_FLUSH) { flushing = true; space_info->flush = 1; } -- 1.7.7.6 -- 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

...free_space_cache); extent_io_tree_cleanup(&fs_info->block_group_cache); diff --git a/extent-tree.c b/extent-tree.c index eede633..ba47688 100644 --- a/extent-tree.c +++ b/extent-tree.c @@ -3172,10 +3172,12 @@ out: int btrfs_free_block_groups(struct btrfs_fs_info *info) { + struct btrfs_space_info *sinfo; u64 start; u64 end; u64 ptr; int ret; + while(1) { ret = find_first_extent_bit(&info->block_group_cache, 0, &start, &end, (unsigned int)-1); @@ -3195,6 +3197,13 @@ int btrfs_free_block_groups(struct btrfs_fs_info *info) clear_extent_dirty(&info-&...

...=============================== --- linux-2.6.35-rc2-gcc.orig/fs/btrfs/extent-tree.c +++ linux-2.6.35-rc2-gcc/fs/btrfs/extent-tree.c @@ -3337,8 +3337,7 @@ struct btrfs_block_rsv *btrfs_alloc_bloc btrfs_init_block_rsv(block_rsv); alloc_target = btrfs_get_alloc_profile(root, 0); - block_rsv->space_info = __find_space_info(fs_info, - BTRFS_BLOCK_GROUP_METADATA); + block_rsv->space_info = __find_space_info(fs_info, alloc_target); return block_rsv; } Index: linux-2.6.35-rc2-gcc/fs/btrfs/dir-item.c =================================================================== --- linux-2.6.35-rc2...

...ns, extent_root, &cache->key, path, 0, 1); if (ret < 0) goto fail; - BUG_ON(ret); + btrfs_fixable_bug_on(ret); leaf = path->nodes[0]; bi = btrfs_item_ptr_offset(leaf, path->slots[0]); @@ -3030,7 +3030,7 @@ static int do_chunk_alloc(struct btrfs_trans_handle *trans, if (!space_info) { ret = update_space_info(extent_root->fs_info, flags, 0, 0, &space_info); - BUG_ON(ret); + btrfs_fixable_bug_on(ret); } BUG_ON(!space_info); @@ -3192,7 +3192,7 @@ static int should_retry_reserve(struct btrfs_trans_handle *trans, trans = btrfs_join_transaction(root, 1);...

...root->fs_info->delalloc_bytes >> PAGE_CACHE_SHIFT); - writeback_inodes_sb_nr_if_idle(root->fs_info->sb, nr_pages, - WB_REASON_FS_FREE_SPACE); + try_to_writeback_inodes_sb_nr(root->fs_info->sb, nr_pages, + WB_REASON_FS_FREE_SPACE); spin_lock(&space_info->lock); if (reserved > space_info->bytes_may_use) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index c77b0bd..2dccb4d 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -2380,7 +2380,7 @@ static int ext4_nonda_switch(struct super_block *sb) * start pushing delalloc when 1/2 of f...

...p returned.So x86 or x86-64 should not reorder it.However,Alpha might reorder it.So memory barrier maybe required in Alpha case. Again,in function find_free_extent the code snippet is if (loop > LOOP_CACHING_NOWAIT || (loop > LOOP_FIND_IDEAL && atomic_read(&space_info->caching_threads) < 2)) { ret = cache_block_group(block_group); BUG_ON(ret); } In this code also I believe the architecture should not reorder the read with atomic_read of caching_threads because of if condition and x86-64 not doing read reordering from software point o...