But if you are planning to
record and start at transaction [14] then its an overkill because
transaction [19 and [20] are already in the disk.
Yes, I'm doing it overkilled.
Ah. Ok.
But it's already much better than scrub all block groups (my original plan).
That's true. Which can be optimized later, but how? and scrub can't
fix RAID1.
Thanks, Anand
Thanks,
Qu
Thanks, Anand
Thanks,
Qu
[3] https://patchwork.kernel.org/patch/10403311/
Further, as we do a self adapting chunk allocation in RAID1, it needs
balance-convert to fix. IMO at some point we have to provide degraded
raid1 chunk allocation and also modify the scrub to be chunk granular.
Thanks, Anand
Any idea on this?
Thanks,
Qu
Unlock: btrfs_fs_info::chunk_mutex
Unlock: btrfs_fs_devices::device_list_mutex
-----------------------------------------------------------------------
Thanks, Anand
--
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
--
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
--
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
--
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
