All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin <newsbox1026@web.de>
To: Phillip Susi <psusi@ubuntu.com>,
	MegaBrutal <megabrutal@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots
Date: Mon, 08 Dec 2014 01:32:24 +0100	[thread overview]
Message-ID: <5484F198.3070206@web.de> (raw)
In-Reply-To: <547E10BA.6000707@ubuntu.com>

Phillip Susi wrote on 02.12.2014 at 20:19:
> On 12/1/2014 4:45 PM, Konstantin wrote:
> > The bug appears also when using mdadm RAID1 - when one of the
> > drives is detached from the array then the OS discovers it and
> > after a while (not directly, it takes several minutes) it appears
> > under /proc/mounts: instead of /dev/md0p1 I see there /dev/sdb1.
> > And usually after some hour or so (depending on system workload)
> > the PC completely freezes. So discussion about the uniqueness of
> > UUIDs or not, a crashing kernel is telling me that there is a
> > serious bug.
>
> I'm guessing you are using metadata format 0.9 or 1.0, which put the
> metadata at the end of the drive and the filesystem still starts in
> sector zero.  1.2 is now the default and would not have this problem
> as its metadata is at the start of the disk ( well, 4k from the start
> ) and the fs starts further down.
I know this and I'm using 0.9 on purpose. I need to boot from these
disks so I can't use 1.2 format as the BIOS wouldn't recognize the
partitions. Having an additional non-RAID disk for booting introduces a
single point of failure which contrary to the idea of RAID>0.

Anyway, to avoid a futile discussion, mdraid and its format is not the
problem, it is just an example of the problem. Using dm-raid would do
the same trouble, LVM apparently, too. I could think of a bunch of other
cases including the use of hardware based RAID controllers. OK, it's not
the majority's problem, but that's not the argument to keep a bug/flaw
capable of crashing your system.

As it is a nice feature that the kernel apparently scans for drives and
automatically identifies BTRFS ones, it seems to me that this feature is
useless. When in a live system a BTRFS RAID disk fails, it is not
sufficient to hot-replace it, the kernel will not automatically
rebalance. Commands are still needed for the task as are with mdraid. So
the only point I can see at the moment where this auto-detect feature
makes sense is when mounting the device for the first time. If I
remember the documentation correctly, you mount one of the RAID devices
and the others are automagically attached as well. But outside of the
mount process, what is this auto-detect used for?

So here a couple of rather simple solutions which, as far as I can see,
could solve the problem:

1. Limit the auto-detect to the mount process and don't do it when
devices are appearing.

2. When a BTRFS device is detected and its metadata is identical to one
already mounted, just ignore it.



  parent reply	other threads:[~2014-12-08  0:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-01 12:56 PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots MegaBrutal
2014-12-01 17:27 ` Robert White
2014-12-01 22:10   ` MegaBrutal
2014-12-01 23:24     ` Robert White
2014-12-02  0:15       ` MegaBrutal
2014-12-02  7:50         ` Goffredo Baroncelli
2014-12-02  8:28           ` MegaBrutal
2014-12-02 11:14             ` Goffredo Baroncelli
2014-12-02 11:54               ` Anand Jain
2014-12-02 12:23                 ` Austin S Hemmelgarn
2014-12-02 19:11                   ` Phillip Susi
2014-12-03  8:24                     ` Goffredo Baroncelli
2014-12-04  3:09                       ` Phillip Susi
2014-12-04  5:15                         ` Duncan
2014-12-04  8:20                           ` MegaBrutal
2014-12-04 13:14                             ` Duncan
2014-12-02 19:14                 ` Phillip Susi
2014-12-08  0:05                 ` Konstantin
2014-12-01 21:45 ` Konstantin
2014-12-02  5:47   ` MegaBrutal
2014-12-02 19:19   ` Phillip Susi
2014-12-03  3:01     ` Russell Coker
2014-12-08  0:32     ` Konstantin [this message]
2014-12-08 14:59       ` Phillip Susi
2014-12-08 22:25         ` Konstantin
2014-12-09 16:04           ` Phillip Susi
2014-12-10  3:10         ` Anand Jain
2014-12-10 15:57           ` Phillip Susi
2014-12-08 17:20       ` Robert White
2014-12-08 22:38         ` Konstantin
2014-12-08 23:17           ` Robert White

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=5484F198.3070206@web.de \
    --to=newsbox1026@web.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=megabrutal@gmail.com \
    --cc=psusi@ubuntu.com \
    /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.