All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: utils version and convert crash
Date: Wed, 2 Dec 2015 09:32:00 -0500	[thread overview]
Message-ID: <565F00E0.6040204@gmail.com> (raw)
In-Reply-To: <pan$85c2b$46f55be$d534ced$bd1aab07@cox.net>

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

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 :)


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-12-02 14:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 12:38 utils version and convert crash Gareth Pye
2015-12-01 12:57 ` Gareth Pye
2015-12-01 14:46   ` Duncan
2015-12-01 15:16   ` Austin S Hemmelgarn
2015-12-01 15:14 ` Duncan
2015-12-01 20:12   ` Gareth Pye
2015-12-01 20:30     ` Austin S Hemmelgarn
2015-12-01 22:22       ` Gareth Pye
2015-12-02  7:07         ` Gareth Pye
2015-12-02 10:01           ` Duncan
2015-12-02 12:07             ` Gareth Pye
2015-12-02 12:25             ` Austin S Hemmelgarn
2015-12-02 13:45               ` Duncan
2015-12-02 14:32                 ` Austin S Hemmelgarn [this message]
2015-12-02 22:14                   ` Gareth Pye
2016-02-28 10:23                     ` Gareth Pye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=565F00E0.6040204@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.