linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Goffredo Baroncelli <kreijack@inwind.it>
Cc: Chris Murphy <lists@colorremedies.com>,
	Andrei Borzenkov <arvidjaar@gmail.com>,
	Justin Engwer <justin@mautobu.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Planning out new fs. Am I missing anything?
Date: Wed, 27 May 2020 12:40:55 -0600	[thread overview]
Message-ID: <CAJCQCtTt0cusvmo-W3vUqmWNbGeH1f3JFSD4gLNBE2_38avd9A@mail.gmail.com> (raw)
In-Reply-To: <0d3b740d-a431-cca0-3841-a85e49ffff9e@libero.it>

On Wed, May 27, 2020 at 10:23 AM Goffredo Baroncelli <kreijack@libero.it> wrote:
>
> Hi All,
>
> On 5/27/20 8:25 AM, Chris Murphy wrote:
> > On Tue, May 26, 2020 at 11:22 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> >>
> >> 27.05.2020 05:20, Chris Murphy пишет:
> >>>
> >>> single, dup, raid0, raid1 (all), raid10 are safe and stable.
> >>
> >> Until btrfs can reliably detect and automatically handle outdated device
> >> I would not call any multi-device profiles "safe", at least unconditionally.
> >
> > I agree.
> >
>
> Checking the generation of each device should be sufficient to detect "outdated" devices. Why this check is not performed ?
> May be that I am missing something ?

But transid isn't unique enough except in isolation. Degraded volumes
are treated completely independently. So if I take a 2x raid1 and
mount each one degraded on separate computers and modify them. Then
join them back together, how can Btrfs resolve the differences? It's a
mess. Yes that is obviously a kind of sabotage. While not literal
sabotage, the effect is the same if you have alternating degraded
drives in successive boots.

So you just cannot use degraded with either fstab or rootflags. It's
bad advice to anyone who gives it and we need to be vigilant about
recommending against it. Maybe the man 5 btrfs page should expressly
say not to include degraded in fstab, or at least warn there are
consequences.

-- 
Chris Murphy

  reply	other threads:[~2020-05-27 18:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25  1:13 Planning out new fs. Am I missing anything? Justin Engwer
2020-05-26 12:47 ` Neal Gompa
2020-05-27  2:20 ` Chris Murphy
2020-05-27  5:22   ` Andrei Borzenkov
2020-05-27  6:25     ` Chris Murphy
2020-05-27 16:23       ` Goffredo Baroncelli
2020-05-27 18:40         ` Chris Murphy [this message]
2020-05-27 19:51           ` Goffredo Baroncelli
2020-05-28  2:14             ` Chris Murphy

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=CAJCQCtTt0cusvmo-W3vUqmWNbGeH1f3JFSD4gLNBE2_38avd9A@mail.gmail.com \
    --to=lists@colorremedies.com \
    --cc=arvidjaar@gmail.com \
    --cc=justin@mautobu.com \
    --cc=kreijack@inwind.it \
    --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).