similar to: [PATCH] Btrfs: fix free space cache when there are pinned extents and clusters

In trying to track down a weird tree log problem I wanted to make sure that the free space cache was actually valid, which we currently have no way of doing. So this patch adds a bunch of support for the free space cache code and then a checker to fsck. Basically we go through and if we can actually load the free space cache then we will walk the extent tree and verify that the free space cache

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

Hello On my HP Compaq dc5800 with Ubuntu 13.04 and their 3.8.0-19-lowlatency kernel, I''ve got quite some kernel traces in the syslog. You can find them below or at http://pastebin.com/bLXPBX67 (to avoid line breaks…). These kernel traces all begin with: WARNING: at fs/btrfs/free-space-cache.c:921 __btrfs_write_out_cache+0x6b9/0x9a0 [btrfs]() Most of the time, it starts with: Call

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

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

Yan Zheng hit a problem where we tried to remove some free space but failed because we couldn''t find the free space entry. This is because the free space was held within a bitmap that had a starting offset well before the actual offset of the free space, and there were free space extents that were in the same range as that offset, so tree_search_offset returned with NULL because we

If we are looking for a cluster in a particularly sparse or fragmented block group, we will do a lot of looping through the free space tree looking for various things, and if we need to look at bitmaps we will endup doing the whole dance twice. So instead add the bitmap entries to a temporary list so if we have to do the bitmap search we can just look through the list of entries we''ve

Hi! With 3.2-rc4 (probably earlier), Ext4 seems to remember what areas it trimmed: merkaba:~> fstrim -v /boot /boot: 224657408 bytes were trimmed merkaba:~> fstrim -v /boot /boot: 0 bytes were trimmed But BTRFS does not: merkaba:~> fstrim -v / /: 4431613952 bytes were trimmed merkaba:~> fstrim -v / /: 4341846016 bytes were trimmed Is it planned to add this feature to BTRFS

hiya! see the attached file for the resolved bug() call. my kernel spit out 185 messages like this: Mar 9 17:15:13 srck@trottelkunde attempt to access beyond end of device Mar 9 17:15:13 srck@trottelkunde 16:42: rw=0, want=0, limit=12289725 right before the bug(). this message didn't get parsed by ksymoops Mar 9 17:15:13 srck@trottelkunde Assertion failure in journal_start() at

We keep hitting bugs in the tree log replay because btrfs_remove_free_space doesn''t account for some corner case. So add a bunch of tests to try and fully test btrfs_remove_free_space since the only time it is called is during tree log replay. These tests all finish successfully, so as we find more of these bugs we need to add to these tests to make sure we don''t regress in

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

I recently bought 2 different USB flash disks. These are some cheap no-name devices. Their parameters: bytes C/H/S ID 4194304512 509/255/63 Vendor: Generic Model: USB Flash Drive Rev: 1.00 ANSI SCSI revision: 02 4288676352 1023/132/62 Vendor: USB Model: USB 2.0 Rev: 1.00 ANSI SCSI revision: 02 When I put a FAT32 filesystem on them,

I have a usb hd that I use for backup. Occasionally it dies. scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): read_inode_bitmap: Cannot read inode bitmap -

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)

The memory allocation failure is BUG_ON in add_excluded_extent (following the code path). No need to BUG_ON -ENOMEM inside btrfs_alloc_logged_file_extent. Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> --- fs/btrfs/extent-tree.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 95492cc..9b9a6fa 100644 ---

If we have particularly full nodes, we could call btrfs_node_blockptr up to 32 times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the extent buffer while we look for readahead targets. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git

If there''s an ongoing transaction when the uuid scan kthread attempts to create one, the kthread will block, waiting for that transaction to finish while it''s keeping locks on the tree root, and in turn the existing transaction is waiting for those locks to be free. The stack trace reported by the kernel follows. [36700.671601] INFO: task btrfs-uuid:15480 blocked for more than

Hello, This patch fixes a problem where we end up seeking too much when *last_ptr is valid. This happens because btrfs_lookup_first_block_group only returns a block group that starts on or after the given search start, so if the search_start is in the middle of a block group it will return the block group after the given search_start, which is suboptimal. This patch fixes that by doing a

Modern hardware relies primarily on memory mapped I/O which is typically at addresses that are not mapped by the kernels initial page tables, which makes using them currently unusable for early debugging print support. So this patch set digs in and fixes the early page tables on both arch/i386 and arch/x86_64 so that set_fixmap works with our initial boot page tables. All that is needed is that