similar to: [PATCH] btrfs: make errors in btrfs_num_copies less noisy

We discussed using the top bits of the chunk type field field to store a number of redundant disks -- so instead of RAID5, RAID6, etc., we end up with a single ''RAID56'' flag, and the amount of redundancy is stored elsewhere. This attempts it, but I hate it and don''t really want to do it. The type field is designed as a bitmask, and _used_ as a bitmask in a number of

Unfortunately my laptop deadlocks from time to time, and too often it triggers this bug in btrfs which is quite hard to recover from. The bigger problem is that all the user sees (if anything) is seemingly unrelated info, namely, "RIP: btrfs_num_copies+0x42/0x0b" or somesuch http://marc.merlins.org/tmp/btrfs_num_copies.jpg It''s only if you have serial console, or netconsole,

The type of some functions that return only 0 is changed to ''void''. In addition, the check on the return value in the caller of these functions becomes unnecessary. So, these check is removed. Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/async-thread.c | 17 ++++-------- fs/btrfs/async-thread.h | 4 +- fs/btrfs/compression.c | 14 ++++------

This reverts commit 5500cdbe14d7435e04f66ff3cfb8ecd8b8e44ebf. We had numerous reports of premature ENOSPC that were bisected to this patch. Reverting will not break things but a warning in ''use_block_rsv'' may show up in the syslog. There''s no alternative fix in sight and the ENOSPC problem affects all 3.3 btrfs users during normal filesystem use. CC:

Extend mkfs options to specify optional or potentially backwards incompatible features. Signed-off-by: David Sterba <dsterba@suse.cz> --- man/mkfs.btrfs.8.in | 9 ++++ mkfs.c | 124 +++++++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 123 insertions(+), 10 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index a3f1503..548e754 100644 ---

The condition can be relaxed to accept also 0 which will delete unoccupied chunks and does not need space for the actual data relocation. Until there is an automatic empty chunk reclaim, we can use this as a last resort option under enospc. CC: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: David Sterba <dsterba@suse.cz> --- Also needs progs update, but is not required for the

In support of the recently added capability to remount with lzo compression, provide a helper function to check the compression INCOMPAT flags when remounting with lzo compression, and set the flags if necessary. Also, implement the new helper function when defragmenting with explicit lzo compression and when setting the default subvolume. Signed-off-by: Mitch Harder

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

fs_info->last_trans_committed is a 64bits variant, we might get a wrong value on the 32bit machines if we access it directly. Fix it by atomic operation. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/ctree.h | 2 +- fs/btrfs/disk-io.c | 2 +- fs/btrfs/file.c | 2 +- fs/btrfs/ioctl.c | 2

fs_info->last_trans_log_full_commit is a 64bits variant, we might get a wrong value on the 32bit machines if we access it directly. Fix it by atomic operation. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/ctree.h | 2 +- fs/btrfs/extent-tree.c | 3 ++- fs/btrfs/inode.c | 3 ++- fs/btrfs/tree-log.c |

For some asynchronous threads, such as submit worker and cache worker, we limit their thread pool size when mounting. So we also need to do such things when remounting. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> --- fs/btrfs/super.c | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 83d6f9f..a58e834 100644 ---

If you look the code carefully, you will see all the tree_mod_alloc() has to use GFP_ATOMIC. However, the original code pass the wrong arg gfp_t in some places, this dosen''t cause any problems, because in the tree_mod_alloc(), it ignores arg gfp_t and just use GFP_ATOMIC directly, this is not good. However, i think we should try best not to allocate with GFP_ATOMIC, so i keep the gfp_t

Hello, Ok here are all my fsync changes, including the fix for the put_transaction stuff that I posted earlier. I figure it'll be easier to just commit it as one thing then each individual peice. The additional thing that I did was add a radix tree that tracks the current outstanding transactions. I also added a field to the in memory btrfs inode that keeps track of the last transaction

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

The messages btrfs: unlinked 123 orphans btrfs: truncated 456 orphans are not useful to regular users and raise questions whether there are problems with the filesystem. Signed-off-by: David Sterba <dsterba@suse.cz> --- fs/btrfs/inode.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 315a515..41a4d9c 100644 ---

We do log replay in a single transaction, so it''s not good to do unbound operations during replaying log. This patch makes orphan inodes cleanup executed after replaying log. It also avoid doing other unbound operations such as truncating a file during replaying log. These unbound operations are postponed to the orphan inode cleanup stage. Signed-off-by: Yan Zheng

The new mount option is set after parsing the remount arguments, so it is wrong that checking the autodefrag is close or not at btrfs_remount_prepare(). Fix it. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/super.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 68a29a1..0f03569 100644 ---

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm