similar to: btrfs_start_delalloc_inodes livelocks when creating snapshot under IO

Hi all. I was doing some testing with writing out data to a BTFS filesystem with the compress-force option. With 1 program running, I saw btfs-delalloc taking about 1 CPU worth of time, much as could be expected. I then started up 2 programs at the same time, writing data to the BTRFS volume. btrfs-delalloc still only used 1 CPU worth of time. Is btrfs-delalloc threaded, to where it can use

Liu fixed part of this problem and unfortunately I steered him in slightly the wrong direction and so didn''t completely fix the problem. The problem is we limit the size of the delalloc range we are looking for to max bytes and then we try to lock that range. If we fail to lock the pages in that range we will shrink the max bytes to a single page and re loop. However if our first page

When using delalloc workers in a non-waiting way (like for enospc handling) we can end up not actually waiting for the dirty pages to be started if we have compression. We need to add an extra filemap flush to make sure any async extents that have started are actually moved along before returning. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- fs/btrfs/inode.c | 18

So both Liu and I made huge messes of find_lock_delalloc_range trying to fix stuff, me first by fixing extent size, then him by fixing something I broke and then me again telling him to fix it a different way. So this is obviously a candidate for some testing. This patch adds a pseudo fs so we can allocate fake inodes for tests that need an inode or pages. Then it addes a bunch of tests to make

If we flush inodes with pending delalloc in a transaction, we may join the same transaction handler more than 2 times. The reason is: Task use_count of trans handle commit_transaction 1 |-> btrfs_start_delalloc_inodes 1 |-> run_delalloc_nocow 1 |-> join_transaction 2 |-> cow_file_range 2 |-> join_transaction 3 In fact, cow_file_range needn''t

Hello all. What we have: SL6 - kernel 2.6.32-131.2.1.el6.x86_64 btrfs on mdadm RAID5 with 8 HDD - 27T partition. I see this at top: 1182 root 20 0 0 0 0 R 100.0 0.0 16:39.73 [btrfs-delalloc-] And LA is grow. What is this and how can I fix it? -- Best regards, Proskurin Kirill -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of

When testing with max_extents=4k, we enospc out really really early. The reason for this is we really overwhelm the system with our worst case calculation. When we try to flush delalloc, we don''t want everybody to wait around forever, so we wake up the waiters when we''ve done some of the work in hopes that its enough work to get everything they need done. The problem with this

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()

Hi Chris- Here''s a simpler version of the patch that drops the unrelated sync_fs stuff. thanks- sage The ''flushoncommit'' mount option forces any data dirtied by a write in a prior transaction to commit as part of the current commit. This makes the committed state a fully consistent view of the file system from the application''s perspective (i.e., it

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;

I''ve just finished installing onto an OCZ Agilent v2 SSD with btrfs as filesystem. However to my surprise I''ve hit an ENOSPC condition one one of the partitions within less than a day of uptime, while the filesystem on that partition only reported 50% to be in use, which is far from the 75% limit people mention on the ML. Note that this occurs using a vanilla 2.6.32-rc5 kernel

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

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

We are running a benchmark that does single threaded 512 KB writes to a LUN on a CLARiiON storage array. The dual Xeon host (Dell 2650) with 4 GB of memory runs RHEL 4U3 We measured the write bandwidth for writes to the block device corresponding to the lun (e.g. /dev/sdb), a file in an ext2 filesystem and to a file in an ext3 file system. Write b/w for 512 KB writes Block device 312 MBps Ext2

I found that I''m able to provoke undefined behaviour with 2.6.38 with extent defragmenting + recompression, eg: mkfs.btrfs /dev/sdb mount /dev/sdb /mnt cp -xa / /mnt find /mnt -print0 | xargs -0 btrfs filesystem defragment -vc After a short time, I was seeing what looked like a secondary effect [1]. Reproducing with lock instrumentation reported recursive spinlock acquisition, probably

Chris: I''m consistently getting oopses when running fsstress against both single and multiple device compressed btrfs filesystems using kernels built from the current btrfs-unstable. In this report, I''m describing an incident with a single device filesystem. Once the oops occurs, all I/O appears to stop though iowait is still reported, and fsstress does not make apparent

We only need an async starter if we can''t make a GFP_NOFS allocation in our current path. This is the case for the endio stuff since it happens in IRQ context, but things like the caching thread workers and the delalloc flushers we can easily make this allocation and start threads right away. Also change the worker count for the caching thread pool. Traditionally we limited this to 2

try_to_writeback_inodes_sb_nr returns 1 if writeback is already underway, which is completely fraking useless for us as we need to make sure pages are actually written before we go and check if there are ordered extents. So replace this with an open coding of try_to_writeback_inodes_sb_nr minus the writeback underway check so that we are sure to actually have flushed some dirty pages out and will

All, I'm requesting comments from the expert readers of ext3-users on these notes for tuning ext3 for performance. Most helpful would be feedback pertinent to RHEL 5; as XFS isn't supported under Red Hat Enterprise Linux these items are an attempt to match XFS performance with ext3. These items were culled from a number of sources. Will they be effective for achieving the performance

We forget to clear inode''s dirty_bytes and EXTENT_DIRTY at the end of write. Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> --- fs/btrfs/file.c | 1 - fs/btrfs/inode.c | 5 ++++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index e7872e4..3f3b4a8 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1150,7 +1150,6 @@