From: Kent Overstreet <kent.overstreet@gmail.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Harald Dunkel <harri@afaics.de>, linux-kernel@vger.kernel.org
Subject: Re: bcache vs bcachefs
Date: Wed, 7 Sep 2016 07:55:52 -0800 [thread overview]
Message-ID: <20160907155552.4fqndafa7vepattr@kmo-pixel> (raw)
In-Reply-To: <5a97b9e7-4928-3d3f-a841-2f9198d8f45d@gmail.com>
On Wed, Sep 07, 2016 at 10:34:15AM -0400, Austin S. Hemmelgarn wrote:
> On 2016-09-06 20:55, Kent Overstreet wrote:
> > On Tue, Sep 06, 2016 at 11:46:28AM +0200, Harald Dunkel wrote:
> > > Hi folks,
> > >
> > > I am pretty hesitant replacing the rock-solid ext4 by bcachefs on my servers.
> > > Meaning no offense, but surely I would prefer to have ext4 with a thin "SSD
> > > caching layer" over a completely different filesystem, potentially with alot
> > > of teething troubles.
> > >
> > > Question: Is bcache EOL or can I rely on it for the next 5 to 10 years?
> >
> > bcache is not EOL - it's still receiving bugfixes.
> >
> > That said though, there's no reason to expect a long teething period with
> > bcachefs, it's already more reliable than btrfs in single device mode.
> >
> I'd be curious to see any actual data you have to back that up, especially
> regarding what kernel and userspace were involved with the BTRFS testing.
I'm not a btrfs user, I'm mostly going off feedback from bcachefs users (many or
most of whom are or have been btrfs users too).
On the bcachefs side, here's what we've seen so far:
- No one has lost data or seen any corruption when using the currently
supported feature set (multiple devices and caching are not stable just yet).
I believe the worst bug anyone's hit was 0 length symlinks after unclean
shutdown, and also 0 length files because we hadn't implemented the
workarounds for applications that don't fsync yet.
- I _believe_ no one's seen any crashes/deadlocks/hangs in supported
configurations - there was a report of a deadlock, but I believe he was using
tiering and it hasn't reproduced since.
I haven't asked for details about the btrfs issues the bcachefs users have seen
(one guy mentioned his 20 core machine panics running btrfs as the reason he was
considering switching it to bcachefs).
Smaller sample size, unscientific comparisons, etc. etc. but it's certainly
looking more robust so far.
That said, I'm not advocating people rush out to throw bcachefs on their servers
or use it without backups yet, it's still young and needs more widespread
testing.
next prev parent reply other threads:[~2016-09-07 15:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 9:46 bcache vs bcachefs Harald Dunkel
2016-09-07 0:55 ` Kent Overstreet
2016-09-07 14:34 ` Austin S. Hemmelgarn
2016-09-07 15:55 ` Kent Overstreet [this message]
2016-09-08 3:01 ` Theodore Ts'o
2016-09-08 4:24 ` Kent Overstreet
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=20160907155552.4fqndafa7vepattr@kmo-pixel \
--to=kent.overstreet@gmail.com \
--cc=ahferroin7@gmail.com \
--cc=harri@afaics.de \
--cc=linux-kernel@vger.kernel.org \
/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