From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Response to Bcachefs Claims
Date: Tue, 25 Aug 2015 13:59:35 -0400 [thread overview]
Message-ID: <55DCAD07.1020500@gmail.com> (raw)
In-Reply-To: <CAJCQCtTSU08EjVrYGyL5TuXsEtTEmkAkpZ4XjM5rMXVZLQsjPA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
On 2015-08-25 12:39, Chris Murphy wrote:
> On Tue, Aug 25, 2015 at 9:22 AM, Vincent Olivier <vincent@up4.com> wrote:
>
>> For my own sake and other's I would like to maintain (if nobody is already working on that nor needs any help) a centralized human-readable digest of known issues that would be featured prominently on top of the Btrfs wiki. I would merge the Gotchas page and the various known issues pages (including the various multi-device mount gotchas here and there).
>
> Some way to organize problems by distribution would be needed to be complete.
>
> For example I don't have the discover & mount by label or uuid problem
> you mention on Fedora, since forever. I haven't experienced it on
> Fedora 19/20 which is approximately what CentOS 7 is based on. To
> figure that out means using one or more boot parameters:
> systemd.log_level=debug or rd.udev.debug or rd.debug to find out
> what's happening.
That would be because the Fedora initrd does a device scan before trying
to mount root. Most of the big distro's do this now, but of course you
need to be using an initrd for it to work.
> The one problem case I still have with the latest versions is multiple
> device Btrfs volume UUID doesn't exist when 1 or more devices are
> missing.
I've seen this myself, but only sometimes. Based on my own testing, it
only seems to happen when one of the disks with a system chunk on it is
missing (for example, in a 3 device raid1 setup, one of the disks won't
have a system chunk on it, and if disk goes missing, I can still mount
by UUID fine).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-08-25 17:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 15:22 Response to Bcachefs Claims Vincent Olivier
2015-08-25 15:53 ` Austin S Hemmelgarn
2015-08-25 23:17 ` Suman Chakravartula
2015-08-25 16:13 ` Roman Mamedov
2015-08-25 17:55 ` Austin S Hemmelgarn
2015-08-25 16:27 ` Chris Mason
2015-08-25 16:39 ` Chris Murphy
2015-08-25 17:59 ` Austin S Hemmelgarn [this message]
2015-08-25 19:58 ` Chris Murphy
2015-08-26 1:17 ` Duncan
2015-08-26 19:24 ` Vincent Olivier
2015-08-29 11:17 ` David Sterba
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=55DCAD07.1020500@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.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.