linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: Unrecoverable fs corruption?
Date: Mon, 04 Jan 2016 01:05:02 +0100	[thread overview]
Message-ID: <1451865902.6411.6.camel@scientia.net> (raw)
In-Reply-To: <pan$e83b6$5156a07d$651aae24$9dda2c0a@cox.net>

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

On Sun, 2016-01-03 at 15:00 +0000, Duncan wrote:
> But now that I think about it, balance does read the chunk in ordered
> to 
> rewrite its contents, and that read, like all reads, should normally
> be 
> checksum verified
That was my idea.... :)

>  (except of course in the case of nodatasum, which nocow 
> of course implies).
Though I haven't had the time so far to reply on the most recent posts
in that thread,... I still haven't given up on the quest for
checksumming of nodatacow'ed data ;-)


> So a balance completed without error /may/ 
> effectively indicate a scrub would complete without error as
> well.  But 
> it wasn't specifically designed for that, and if it does so, it's
> only 
> doing it because all reads are checksum verified, not because it's 
> actually purposely doing a scrub.
Well sure... this is however an interesting concept to think about for
the long term future.

I'd expect that in some distant future, we'd have powerful userland
tools that do maintenance and health monitoring of btrfs filesystems,
including e.g. automated scrubs, defrags and so on.

Especially on large filesystems all these operations tend to take large
amounts of time and may even impact the lifetime of the storage
device(s)... so it would be clever if certain such operations could be
kinda "merged", at least for the purposes of getting the results.
As in the above example, if one would anyway run a full balance, the
next scrub may be skipped because one is just doing one.
Similar for defrag.


> And even if balance works to verify no checksum errors, I don't
> believe 
> it would correct them or give you the detail on them that a scrub
> would.
I'd have expected that that read errors are (if possible because of
block copies) are repaired as soon as they're encountered... isn't that
the case?

  
> And if there is an error, it'd be a balance error, which might or
> might 
> not actually be a scrub error.
Sure, but it shouldn't be difficult to collect e.g. scrub stats during
balance as well.


:-)

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

  reply	other threads:[~2016-01-04  0:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-31 23:36 Unrecoverable fs corruption? Alexander Duscheleit
2016-01-01  1:22 ` Chris Murphy
2016-01-01  8:13   ` Duncan
2016-01-02  4:32     ` Christoph Anton Mitterer
2016-01-03 15:00       ` Duncan
2016-01-04  0:05         ` Christoph Anton Mitterer [this message]
2016-01-06  7:35           ` Duncan
2016-01-02 10:53     ` Alexander Duscheleit
2016-01-02 21:19       ` Henk Slager
2016-01-03 15:53         ` Duncan
2016-01-03 16:24           ` Martin Steigerwald
2016-01-03 16:08       ` Duncan

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=1451865902.6411.6.camel@scientia.net \
    --to=calestyo@scientia.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).