From: Roman Mamedov <rm@romanrm.net>
To: waxhead <waxhead@dirtcellar.net>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS list of grievances
Date: Fri, 27 Sep 2024 21:27:55 +0500 [thread overview]
Message-ID: <20240927212755.5b24ecd4@nvm> (raw)
In-Reply-To: <aebe9671-6f44-9d20-f077-b19e09fa1fcd@dirtcellar.net>
On Fri, 27 Sep 2024 13:20:14 +0200
waxhead <waxhead@dirtcellar.net> wrote:
> 1. FS MANAGEMENT
> ================
> BTRFS is rather simple to manage. We can add/remove devices on the fly,
> balance the filesystem, scrub, defrag, select compression algorithms
> etc. Some of these things are done as mount options, some as properties
> and some by issuing a command that process something.
I will add my annoyance or rather a showstopper.
Consider a RAID1 of two 20TB disks. One disk disconnects and the system
operates on just the remaining one for a few days.
Side note: will Btrfs even agree to operate in such state without constant
stream of errors to dmesg?
Then the disk is reconnected to the system.
For a start, are we even able to cleanly forget an abruptly disappeared drive
in RAID1, and then re-add it back when the same disk it reappears (under a
different /dev/sdX location)? Without remounting and reboot?
Secondly, it feels like you'll be extremely lucky not to die a fiery death of
"parent transid mismatch errors" right away with Btrfs, after this.
Or if not, then how do you get from there to a consistent state? Run a scrub,
make the system reread the entire 40 TB of data, correcting errors and lack of
duplication where necessary.
Meanwhile, mdadm RAID1: thanks to the Write-intent bitmap, after a re-add the
RAID resyncs just the small changed areas from the continuously running disk
to the temporarily-absent one, and the array consistency is almost instantly
restored, in many cases just with a few GBs read and written.
Or maybe I underestimate the current Btrfs capabilities here?
--
With respect,
Roman
next prev parent reply other threads:[~2024-09-27 16:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-27 11:20 BTRFS list of grievances waxhead
2024-09-27 16:27 ` Roman Mamedov [this message]
2024-09-27 18:05 ` Remi Gauvin
2024-09-27 19:01 ` Colin S
2024-10-02 19:31 ` Chris Murphy
2024-10-02 23:18 ` Colin S
2024-09-28 10:15 ` Paul Jones
2024-09-28 17:51 ` Roman Mamedov
2024-09-27 17:44 ` Mark Harmstone
2024-09-30 21:43 ` Goffredo Baroncelli
2024-10-03 17:10 ` Goffredo Baroncelli
2024-10-03 17:26 ` Remi Gauvin
2024-10-03 18:24 ` Goffredo Baroncelli
2024-10-03 18:32 ` Remi Gauvin
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=20240927212755.5b24ecd4@nvm \
--to=rm@romanrm.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=waxhead@dirtcellar.net \
/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.