From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Vincent Olivier <vincent@up4.com>, linux-btrfs@vger.kernel.org
Subject: Re: Response to Bcachefs Claims
Date: Tue, 25 Aug 2015 11:53:58 -0400 [thread overview]
Message-ID: <55DC8F96.2010506@gmail.com> (raw)
In-Reply-To: <1440516154.040713246@apps.rackspace.com>
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
On 2015-08-25 11:22, Vincent Olivier wrote:
> Hi,
>
> I have been using Btrfs for almost a year now with a 16x4TB RAID10 and its 8x4TB RAID0 backup (using incremental snapshots diffs). I have always tried to stay at the latest stable kernel (currently 4.1.6). But I might be moving to Fedora 22 because Centos 7 has significant incompatibilities with the 4.1.x kernel series.
>
> I have seen the news about Bcachefs aiming to be Btrfs-complete while being extX-stable.
>
> What are the chances Bcachefs beats Btrfs at being the Linux kernel's next "official" file system ? I chose Btrfs over ZFS because it seemed like the only "next-gen" heir to ext4/xfs.
>
> I have been having a few problems with Btrfs myself. I have only one that remains unresolved : I haven't found the best way to mount Btrfs at boot time. "LABEL=" won't work for known reasons (I don't understand however why a mount can't do its own "device scan" transparently). "UUID=" won't work for unknown reasons (haven't got a reply on this, maybe it's the same as "LABEL="). And I will use /dev/* in fstab for stability reasons. Right now I'm mounting the fs manually after a "device scan" and picking up the first device that shows up in the "fi show" run. I can "live" with that but I suppose that things like this contribute to the feeling that Btrfs is actually still experimental contrarily to claims that it is production-ready.
>
> 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).
>
> Answers ? Comments ? Help ?
First off, I think this is a wonderful idea. The list of known issues
isn't always particularly up to date, and isn't as trivial to find as it
should be.
Secondly, as far as UUID= not working from the kernel commandline, I
believe it's for the same reason that LABEL= doesn't work consistently.
I would like to point out that LABEL= does work if you use a sane
initramfs (I boot my desktop using it, although I'm only using an
initramfs because I have root on a pair of LVM volumes), and I _think_
it might also work if you pas device= options in the rootoptions= string.
Thirdly, there is one issue that I haven't seen anyone else mention and
that is not present on any of the wiki pages at last check:
If you try to use BTRFS on top of LVM thin-provisioning (or
theoretically any dm-thinp setup), and turn off zeroing of newly
allocated blocks, this can cause BTRFS to have corruption issues. I
think this is actually a dm-thinp issue, not a BTRFS one (turning this
option off does not clear the discard_zeroes_data flag for the device,
which I would assume that BTRFS trusts), but is still worth mentioning.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-08-25 15:54 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 [this message]
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
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=55DC8F96.2010506@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=vincent@up4.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.