On Sun, Dec 27, 2015 at 6:09 PM, Christoph Anton Mitterer <cales...@scientia.net> wrote: > On Sun, 2015-12-27 at 17:58 -0700, Chris Murphy wrote: >> I don't see a good use case for scrubbing a degraded array. First >> make >> the array healthy, then scrub. > As I've said, I agree basically... but *if* scrubbing a degraded fs > leads to even more errors (apart from the fact that you may loose > another device for hardware reasons while scrubbing), than either this > needs to be fixed *or* scrub mustn't be started on a degraded array (in > the sense that software prevents it). > > Consider you have a weekly cron job that scrubs, which runs while the > array is degraded.
The scrub should fail gracefully (exit 1). > > >> But I've not tested this with mdadm or >> lvm raid. I don't know how they behave. > Don't know, but for them it makes not so much sense, as their scrub is > different from ours... they have no checksums and can only tell whether > the RAID itself is consistent, which it is of course not when degraded. > It does perhaps make sense in any mirrored RAIDs (e.g. when you have a > 4 disk RAID1, which is degraded and 1 disk is missing,... it may still > be worth to scrub the remaining 3,...) > > >> But even if either of them >> tolerate it, it's a legitimate design decision for Btrfs developers >> to >> refuse supporting the scrub of a degraded array. Same for balancing >> for that matter. > Sure... but still it needs to be handled gracefully... i.e. not more > damage and reasonable userland output which people will understand. Yes. I'd want scrub to immediately fail in a degraded case, because the higher workload added by the scrub itself could cause additional device failures sooner. And that would negatively impact the ability to get the array healthy again with a rebuild - during which time you wouldn't want the scrub running anyway. -- Chris Murphy -- 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
