similar to: warning in btrfs_free_block_groups

I''ve been working on running down intermittent ENOSPC issues. I can only seem to replicate ENOSPC errors when running zlib compression. However, I have been seeing similar ENOSPC errors to a lesser extent when playing with the LZ4HC patches. I apologize for not following up on this sooner, but I had drifted away from using zlib, and didn''t notice there was still an issue. My

Reserve metadata space for extent 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

Hello, So there is an odd case where we can possibly return -ENOSPC when there is in fact space to be had. I think I finally have a hold on what the problem is, it only happens with Metadata writes, and happens _very_ infrequently. What has to happen is we have to allocate have allocated out of the first logical byte on the disk, which would set last_alloc to first_logical_byte(root, 0), so

I''ve been working on btrfs-image and I kept seeing these leaks pop up on valgrind so I''m just fixing them. We don''t properly cleanup the device cache, the chunk tree mapping cache, or the space infos on close. With this patch valgrind doesn''t complain about any memory leaks running btrfs-image. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>

the tree log recover code expects no free space cached before it executes. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 4/fs/btrfs/extent-tree.c 8/fs/btrfs/extent-tree.c --- 4/fs/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)

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

This patch finally gives us full proper -ENOSPC handling 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

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

Hi, this shown up today. I had to do a hard reboot as graceful hanged on sync(). ------------[ cut here ]------------ kernel BUG at fs/btrfs/delayed-inode.c:1466! invalid opcode: 0000 [#1] SMP CPU 10 Modules linked in: btrfs zlib_deflate lzo_compress ipmi_devintf autofs4 be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi

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

These are all the cases where a variable is set, but not read which are really bugs. - Couple of incorrect error handling fixed. - One incorrect use of a allocation policy - Some other things Still needs more review. Found by gcc 4.6''s new warnings Cc: chris.mason@oracle.com cc: linux-btrfs@vger.kernel.org Signed-off-by: Andi Kleen <ak@linux.intel.com> ---

Hi - I''m trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora kernel). I''m just doing a tar-to-tar copy onto the file system with compress- force=zlib. Here are some traces of the stuck processes. flush-btrfs-5 seems to be stuck: Jul 8 11:49:40 xback2 kernel: [74920.681032] flush-btrfs-5 D ffff88003c7bae60 0 11712 2 0x00000080 Jul 8 11:49:40 xback2 kernel:

Document those places in the btrfs code which are BUGing on non-fatal error conditions that should be handled by proper error paths. This makes it easier to distinguish between what needs fixing versus which BUG_ON''s we might want to keep (to trap code bugs, unexpected inconsistencies, etc). Do this with a trivial macro, ''btrfs_fixable_bug_on'' which just defines to

writeback_inodes_sb(_nr)_if_idle() is re-implemented by replacing down_read() with down_read_trylock() because - If ->s_umount is write locked, then the sb is not idle. That is writeback_inodes_sb(_nr)_if_idle() needn''t wait for the lock. - writeback_inodes_sb(_nr)_if_idle() grabs s_umount lock when it want to start writeback, it may bring us deadlock problem when doing umount.

We still need to say we''re flushing if we''re limit flushing to keep somebody from coming in and stealing our reservation. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- fs/btrfs/extent-tree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index ad8786b..721efb8 100644 ---

Hi all, It seems like memory barrier is not required in cached_block_group.I am looking at kernel 2.6.34-rc2. cache_block_group(struct btrfs_block_group_cache *cache) { smp_mb(); if (cache->cached != BTRFS_CACHE_NO) return 0; .... } This function is called from btrfs_alloc_logged_file_extent and find_free_extent. In btrfs_alloc_logged_file_extent the code snippet is as follows

Hello, (this is a recap of yesterday''s discussion on BTRFS IRC, also to save relevant pastes before pastebins expire) I have my /home on btrfs; a cronjob makes one snapshot every 30 minutes; these snapshots are kept for 24-48 hours, then deleted in batches. This is a 16K Leaf/Node BTRFS on top of mdadm RAID1. As system uptime approached 2 weeks, I started noticing that the free space

The reason the deadlock is that: Task Btrfs-cleaner umount() down_write(&s->s_umount) sync_filesystem() do auto-defragment and produce lots of dirty pages close_ctree() wait for the end of btrfs-cleaner start_transaction reserve space shrink_delalloc() writeback_inodes_sb_nr_if_idle()

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