From: Chris Mason <clm@fb.com>
To: Vincent Olivier <vincent@up4.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: Response to Bcachefs Claims
Date: Tue, 25 Aug 2015 12:27:03 -0400 [thread overview]
Message-ID: <20150825162703.GA25661@ret.masoncoding.com> (raw)
In-Reply-To: <1440516154.040713246@apps.rackspace.com>
On Tue, Aug 25, 2015 at 11:22:34AM -0400, 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.
Kent is a smart guy, and I'm always glad to see more work in Linux
filesystems. We all work on the parts we think are important and people
use the best tool they can find for their workloads. Sometimes that'll
be btrfs, sometimes not. Btrfs has certainly come a long way and is
continuing to improve pretty dramatically.
>
> 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.
>
LABEL= and UUID= both need a scan on multi device filesystems. If your
initrd does it, things will work fine.
-chris
next prev parent reply other threads:[~2015-08-25 16:27 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 [this message]
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=20150825162703.GA25661@ret.masoncoding.com \
--to=clm@fb.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 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).