This patch reverts the commit
95669976bd7d30ae265db938ecb46a6b7f8cb893
Btrfs: don't consider the missing device when allocating new chunks
Original code was correct as in the deleted comments
/*
* we add in the count of missing devices because we want
* to make sure that any RAID levels on a degraded FS
* continue to be honored.
*/
The following RFC patch will take care of the original bug
btrfs: create degraded-RAID1 chunks
Signed-off-by: Anand Jain <anand.j...@oracle.com>
---
fs/btrfs/extent-tree.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 53e12977bfd0..bf60da1020b7 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3968,12 +3968,19 @@ static u64 get_restripe_target(struct btrfs_fs_info
*fs_info, u64 flags)
*/
static u64 btrfs_reduce_alloc_profile(struct btrfs_root *root, u64 flags)
{
- u64 num_devices = root->fs_info->fs_devices->rw_devices;
+ u64 num_devices;
u64 target;
u64 raid_type;
u64 allowed = 0;
/*
+ * we add in the count of missing devices because we want
+ * to make sure that any RAID levels on a degraded FS
+ * continue to be honored.
+ */
+ num_devices = root->fs_info->fs_devices->rw_devices +
+ root->fs_info->fs_devices->missing_devices;
+ /*
* see if restripe for this chunk_type is in progress, if so
* try to reduce to the target profile
*/
@@ -9146,7 +9153,13 @@ static u64 update_block_group_flags(struct btrfs_root
*root, u64 flags)
if (stripped)
return extended_to_chunk(stripped);
- num_devices = root->fs_info->fs_devices->rw_devices;
+ /*
+ * we add in the count of missing devices because we want
+ * to make sure that any RAID levels on a degraded FS
+ * continue to be honored.
+ */
+ num_devices = root->fs_info->fs_devices->rw_devices +
+ root->fs_info->fs_devices->missing_devices;
stripped = BTRFS_BLOCK_GROUP_RAID0 |
BTRFS_BLOCK_GROUP_RAID5 | BTRFS_BLOCK_GROUP_RAID6 |
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
