From: Roman Mamedov <rm@romanrm.net>
To: Matt Huszagh <huszaghmatt@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: How to replace a failing device
Date: Thu, 3 Nov 2022 17:18:48 +0500 [thread overview]
Message-ID: <20221103171848.540a9056@nvm> (raw)
In-Reply-To: <87v8nw3dcg.fsf@gmail.com>
On Wed, 02 Nov 2022 20:51:11 -0700
Matt Huszagh <huszaghmatt@gmail.com> wrote:
> 99.99% data rescued with 2 bad sectors. Since I didn't have any trouble
> backing up recent data, I'm optimistic I haven't lost anything of value.
If your backup is incremental and only copies modified files, you can ensure
all other files are also readable by recursively reading them:
find -type f -print0 | xargs -0 cat > /dev/null
...for a kind of manual scrub. Unless you had nocow/nodatasum files in there,
any damaged ones will return a read error thanks to Btrfs checksums.
Or maybe you could check if Btrfs scrub has also stopped hanging, given there
are no disk-level unreadable sectors anymore. (And after you have also
upgraded the kernel).
> I'm investigating RAID configurations (probably RAID10) as a way to make
> the process of replacing faulty drives somewhat smoother in the
> future. If you have any opinions on this would be curious to hear
> them. I'll probably also setup a periodic systemd service to run
> smartctl and detect issues (hopefully) earlier.
Btrfs currently does not seem to be famous for smooth disk replacements
unfortunately, even if you would use RAID.
I would suggest keeping up with the good backup schedule, and then rather than
using the Btrfs "single" profile stretched across devices, switch to MergerFS.
That way any disaster on a particular disk leaves other disks and their
independent filesystems completely unaffected.
--
With respect,
Roman
next prev parent reply other threads:[~2022-11-03 12:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-01 19:13 How to replace a failing device Matt Huszagh
2022-11-01 19:32 ` Roman Mamedov
2022-11-01 19:44 ` Roman Mamedov
2022-11-03 3:51 ` Matt Huszagh
2022-11-03 4:19 ` Andrei Borzenkov
2022-11-03 4:25 ` Matt Huszagh
2022-11-03 12:18 ` Roman Mamedov [this message]
2022-11-03 21:39 ` Matt Huszagh
2022-11-03 22:32 ` Roman Mamedov
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=20221103171848.540a9056@nvm \
--to=rm@romanrm.net \
--cc=huszaghmatt@gmail.com \
--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.