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: Wed, 2 Nov 2022 00:44:24 +0500 [thread overview]
Message-ID: <20221102004424.3683a2e0@nvm> (raw)
In-Reply-To: <20221102003232.097748e7@nvm>
On Wed, 2 Nov 2022 00:32:32 +0500
Roman Mamedov <rm@romanrm.net> wrote:
Some afterthoughts...
> Remove this cryptsdc2 from the FS (btrfs dev remove), stop the crypto device,
> wipe sdc2 entirely with wipefs.
That's not "entirely" of course, but just wiping the signatures is enough.
> After "ddrescue" manages to copy whatever it could, power-off and remove the
> old failing "sdd" from the system. Do not boot the main OS with both disks
> still plugged in. You can wipe the failing one later (after verifying the
> created copy is good) on some other PC, or booting into the same rescue system
> again.
After verifying it is good, you can enlarge the Btrfs' opinion of the
partition size on the copied 16TB device, see "btrfs resize devid:max ..."
> > $ sudo btrfs fi df /
> > Data, single: total=3.15TiB, used=2.74TiB
> > System, RAID1: total=32.00MiB, used=432.00KiB
> > Metadata, RAID1: total=110.00GiB, used=18.25GiB
^ A side note, this looks weird, as if at some point you had a ton of tiny
files, and then you removed them. If I'm not mistaken, running:
btrfs fi balance -musage=80 ...
could gain you around 150 GB of usable disk space (as seen in df and
accessible for writing non-tiny files).
But of course do that only after the failing disk problem has been resolved.
And I vaguely remember that at some point the kernel may have started doing
this kind of cleanup automatically.
> > GlobalReserve, single: total=512.00MiB, used=0.00B
--
With respect,
Roman
next prev parent reply other threads:[~2022-11-01 19:44 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 [this message]
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
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=20221102004424.3683a2e0@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.