similar to: [PATCH] Btrfs: fix a deadlock on chunk mutex

Hi I am hitting this Warning reproducible, the workload is a ceph osd, kernel ist 3.1.0-rc5. Best Regards, martin [ 5472.099766] ------------[ cut here ]------------ [ 5472.099833] WARNING: at fs/btrfs/inode.c:2193 btrfs_orphan_commit_root+0xb0/0xc0 [btrfs]() [ 5472.099838] Hardware name: MS-96B3 [ 5472.099842] Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit psmouse sp5100_tco

Hello, I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using the 3.1 kernel, I found a patch for these warnings ( http://marc.info/?l=linux-btrfs&m=131547325515336&w=2) <http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch has already been included in 3.1. Are there any other patches I can try? I''m using

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

We''ve been seeing warnings coming out of the orphan commit stuff forever from ceph. Turns out it''s because we''re racing with checking if the orphan block reserve is set, because we clear it outside of the spin_lock. So leave the normal fastpath checks where they are, but take the spin_lock and _recheck_ to make sure we haven''t had an orphan block rsv added in

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, I have high IO-Wait on the ods (ceph), the osd are running a v3.1-rc9 kernel. I also experience high IO-rates, around 500IO/s reported via iostat. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 6.80 0.00 62.40 18.35 0.04 5.29 0.00 5.29 5.29 3.60 sdb

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

Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the

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

The fault code has been calling file_update_time after ->page_mkwrite after it drops the page lock, but this is annoying because this calls mark_inode_dirty which can fail in Btrfs, so we want to be able to do these updates in ->page_mkwrite so we can get an error back to the user. So get rid of the file_update_time calls in the fault code and push it into everybody who has a

So if you have a mount command that doesn''t use /etc/mtab then it will spit out a different device for the mounted device. So say we have SCRATCH_DEV_POOL="/dev/sda /dev/sdb /dev/sdc" we will turn this into SCRATCH_DEV="/dev/sda" SCRATCH_DEV_POOL="/dev/sdb /dev/sdc" and then when you mkfs this you do _scratch_mkfs $SCRATCH_DEV_POOL which turns into this

This is similar to a previous fix I sent. 1 gig makes us do mixed file block groups for btrfs, so these enospc tests will usually fail because we don''t have space for metadata, which is the case for this test. So jack the size up to 1.5gig so that btrfs can do its normal thing and pass the test. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- tests/generic/256 |

Hello, I was bored this weekend so I hacked up online dedup for Btrfs. It''s working quite well so I think it can be more widely tested. There are two ways to use it 1) Compatible mode - this is a bit slower but will handle being used by older kernels. We use the csum tree to find duplicate blocks. Since it is relatively easy to have crc32c collisions this also involves reading the

2011/10/26 Sage Weil <sage@newdream.net>: > On Wed, 26 Oct 2011, Christian Brunner wrote: >> >> > Christian, have you tweaked those settings in your ceph.conf?  It would be >> >> > something like ''journal dio = false''.  If not, can you verify that >> >> > directio shows true when the journal is initialized from your osd log?

I wanted to see how btrfs compares to other filesystems so I have been running bonnie++ on it. While the results are good(much faster then ext2) every once in awhile I get a kernel oops. I am testing on xubuntu 8.10 with the 2.6.27-7-686 kernel using the latest git sources. Most of the time the oops happens within 20min of running bonnie++ but sometimes it takes a few hours. This happens with and

The freeze rwsem is taken by sb_start_intwrite() and dropped during the commit_ or end_transaction(). In the async case, that happens in a worker thread. Tell lockdep the calling thread is releasing ownership of the rwsem and the async thread is picking it up. Josef and I worked out a more complicated solution that made the async commit thread join and potentially get a later transaction, but

Hello, I just updated and pushed btrfs-next, if it is missing something let me know. I had to kick out the printk formatting patch because it didn''t compile and I didn''t take Miao''s background enospc flushing stuff since some of it didn''t apply and 5/5 hasn''t been updated to force waiting on background flushers. Let me know if I missed anything

Hi everybody, I am using btrfs as my main fs for some time now, but I am experiencing severe performance drawbacks. I can''t qualify the circumstances, but sometimes during disc access the whole system freezes for some time. Maybe somebody could suggest some general things I could try to search for the problem? Thanks in advance, Florian --- Some background information: $ mount |

V2 -> V3: set ''err'' to -ENOMEM when kmalloc() fails. Thanks to Tao. V1 -> V2: Move kmalloc() before mutex_lock(), suggested by Arjan. file_remove_suid() should be called with i_mutex held, file_update_time() too. So move them after mutex_lock(). Plus, check the return value of kmalloc(). Signed-off-by: WANG Cong <amwang@redhat.com> Cc: Arjan

Hello I think, I somewhat destroyed my btrfs filesystem on my Ubuntu 13.04 kernel 3.8.0-25-lowlatency system. It got destroyed, because the system was hanging for some other reason and I had to remove power... When I try to mount my filesystem (there''s only one, with a few subfilesystems), the system crashes. Also btrfsck dies; always like this: a@ask-home:~$ sudo