similar to: [PATCH] Btrfs: force delalloc flushing when things get desperate

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

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

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

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

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

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

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

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

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

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

On 06/30/2011 09:13 PM, Josef Bacik wrote: > On 06/30/2011 10:12 AM, Proskurin Kirill wrote: >> On 06/29/2011 08:14 PM, Josef Bacik wrote: >>>> Ok - I upgrade to 2.6.39-2 but it is seems to all things get worse. >>>> Now I see [btrfs-transacti]& btrfs-endio-wri] 80-100% all the time and >>>> io performance looks like lower then before.

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

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

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

This deadlock comes from xfstests 251. We''ll hold the chunk_mutex throughout the whole of a chunk allocation. But if we find that we''ve used up system chunk space, we need to allocate a new system chunk, but this will lead to a recursion of chunk allocation and end up with a deadlock on chunk_mutex. So instead we need to allocate the system chunk first if we find we''re

Josef''s fs_mark test fs_mark -d /mnt/btrfs-test -D 512 -t 16 -n 4096 -F -S0 on a 2GB single metadata fs leaves about 400Mb of metadata almost unused. This patch reduces metadata chunk allocations by considering the proper metadata chunk size of 200MB in should_alloc_chunk(), not the default 256MB which is set in __btrfs_alloc_chunk(). Signed-off-by: Itaru Kitayama

I suspect this might be related to previous btrfs errors I''ve had on the same filesystem. See: http://python.ca/nas/linux/btrfs_bug.txt The most recent kernel message is: WARNING: at fs/btrfs/extent-tree.c:8239 btrfs_free_block_groups+0x218/0x275() Hardware name: MS-7388 Modules linked in: udf crc_itu_t isofs loop nls_iso8859_1 vboxnetflt vboxdrv nls_utf8 nls_cp437

Greetings all, I see the following issue during snap creation under IO: Transaction commit calls btrfs_start_delalloc_inodes() that locks the delalloc_inodes list, fetches the first inode, unlocks the list, triggers btrfs_alloc_delalloc_work/btrfs_queue_worker for this inode and then locks the list again. Then it checks the head of the list again. In my case, this is always exactly the same