All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.