[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d2a06111-c8c6-cdb6-c8ac-ae7148742786@sandeen.net>
Date: Thu, 6 Jul 2023 14:17:29 -0500
From: Eric Sandeen <sandeen@...deen.net>
To: Kent Overstreet <kent.overstreet@...ux.dev>,
Josef Bacik <josef@...icpanda.com>
Cc: torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-bcachefs@...r.kernel.org,
djwong@...nel.org, dchinner@...hat.com, sandeen@...hat.com,
willy@...radead.org, tytso@....edu, bfoster@...hat.com,
jack@...e.cz, andreas.gruenbacher@...il.com, brauner@...nel.org,
peterz@...radead.org, akpm@...ux-foundation.org,
dhowells@...hat.com
Subject: Re: [GIT PULL] bcachefs
On 7/6/23 12:38 PM, Kent Overstreet wrote:
> Right now what I'm hearing, in particular from Redhat, is that they want
> it upstream in order to commit more resources. Which, I know, is not
> what kernel people want to hear, but it's the chicken-and-the-egg
> situation I'm in.
I need to temper that a little. Folks in and around filesystems and
storage at Red Hat find bcachefs to be quite compelling and interesting,
and we've spent some resources in the past several months to
investigate, test, benchmark, and even do some bugfixing.
Upstream acceptance is going to be a necessary condition for almost any
distro to consider shipping or investing significantly in bcachefs. But
it's not a given that once it's upstream we'll immediately commit more
resources - I just wanted to clarify that.
It is a tough chicken and egg problem to be sure. That said, I think
you're right Kent - landing it upstream will quite likely encourage more
interest, users, and hopefully developers.
Maybe it'd be reasonable to mark bcachefs as EXPERIMENTAL or similar in
Kconfig, documentation, and printks - it'd give us options in case it
doesn't attract developers and Kent does get hit by a bus or decide to
go start a goat farm instead (i.e. in the worst case, it could be
yanked, having set expectations.)
-Eric
Powered by blists - more mailing lists