On 11/02/2017 08:54 AM, Liu Bo wrote:
Here we have defined two flags,
- Fautly
- In_sync
Currently only In_sync is in use, it only matters when device serves
as part of a raid profile. The flag In_sync is decided when mounting
a btrfs and opening a device, by default every device is set with
In_sync, but would not be set if its generation was out of date.
If the device doesn't get resync and to avoid overriding its
generation during writing superblock, if the !In_sync device is still
writeable, its last valid generation will be recorded in
superblock.dev_item.generation instead of superblock.generation, such
that the last valid generation can be retained through several reboot,
btrfs is able to detect the out-of-sync device.
Based on the bug you are trying to address in patch 2/4.
- I still don't get the point the need for explicit flag
In_Sync for the whole disk and not just depend on stripe
for which anyway crc will fail ?
- Here whole disk isn't the problem. Only the stripe which
were missed on the missing disk is the problem.
@@ -6592,6 +6625,14 @@ static int read_one_dev(struct btrfs_fs_info *fs_info,
return -EIO;
}
+ if (!test_bit(In_sync, &device->flags) &&
+ !btrfs_test_opt(fs_info, DEGRADED)) {
+ btrfs_warn(fs_info,
+ "devid %llu uuid %pU is Not in_sync, but we're not under degraded mode",
+ devid, dev_uuid);
+ return -EIO;
+ }
+
degrade option is for the missing device and if user still want to
continue, here its about device with not_In_Sync flag, degrade option
check is not required.
Similarly the test case should be updated as well.
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
