Yeah having a scrub take 9 hours instead of 24 (+ latency of human involvement) would be really nice.
On Thu, Dec 3, 2015 at 1:32 AM, Austin S Hemmelgarn <ahferro...@gmail.com> wrote: > On 2015-12-02 08:45, Duncan wrote: >> >> Austin S Hemmelgarn posted on Wed, 02 Dec 2015 07:25:13 -0500 as >> excerpted: >> >>> On 2015-12-02 05:01, Duncan wrote: >> >> >> [on unverified errors returned by scrub] >>>> >>>> >>>> Unverified errors are, I believe[1], errors where a metadata block >>>> holding checksums itself has an error, so the blocks its checksums in >>>> turn covered are not checksum-verified. >>>> >>>> What that means in practice is that once the first metadata block error >>>> has been corrected in a first scrub run, a second scrub run can now >>>> check the blocks that were recorded as unverified errors in the first >>>> run, potentially finding and hopefully fixing additional errors[.] >> >> >>>> --- >>>> [1] I'm not a dev and am not absolutely sure of the technical accuracy >>>> of this description, but from an admin's viewpoint it seems to be >>>> correct at least in practice, based on the fact that further scrubs as >>>> long as there were unverified errors often did find additional errors, >>>> while once the unverified count dropped to zero and the last read >>>> errors were corrected, further scrubs turned up no further errors. >>>> >>> AFAICT from reading the code, that is a correct assessment. It would be >>> kind of nice though if there was some way to tell scrub to recheck up to >>> X many times if there are unverified errors... >> >> >> Yes. For me as explained it wasn't that big a deal as another scrub was >> another minute or less, but definitely on terabyte-scale filesystems on >> spinning rust, where scrubs take hours, having scrub be able to >> automatically track just the corrected errors along with their >> unverifieds, and rescan just those, should only take a matter of a few >> minutes more, while a full rescan of /everything/ would take the same >> number of hours yet again... and again if there's a third scan required, >> etc. >> >> I'd say just make it automatic on corrected metadata errors as I can't >> think of a reason people wouldn't want it, given the time it would save >> over rerunning a full scrub over and over again, but making it an option >> would be fine with me too. >> > I was thinking an option to do a full re-scrub, but having an automatic > reparse of the metadata in a fixed metadata block would be a lot more > efficient that what I was thinking :) > -- Gareth Pye - blog.cerberos.id.au Level 2 MTG Judge, Melbourne, Australia "Dear God, I would like to file a bug report" -- 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
