LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-bcache@vger.kernel.org
Cc: Kent Overstreet <kent.overstreet@gmail.com>,
	Dave Chinner <dchinner@redhat.com>,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	hare@suse.com
Subject: [PATCH 0/2] bcachefs: on disk data structures, ioctl interface - review requested for upstreaming
Date: Tue,  8 May 2018 18:17:58 -0400	[thread overview]
Message-ID: <20180508221800.2642-1-kent.overstreet@gmail.com> (raw)

So, a few weeks ago I finally showed up at LSF to talk about this filesystem
I've been working on - as well as upstreaming it - and really the whole thing
was surprisingly uneventful; the general response was "start sending out
patches".

Background for anyone who hasn't heard about bcachefs:
https://www.spinics.net/lists/linux-fsdevel/msg121577.html
https://bcachefs.org

Git repo:
https://evilpiepirate.org/git/bcachefs.git

Dave suggested I start out by sending out just the on disk format and ioctl
interface since the whole thing is over 50k lines, so that's what I'm doing
here. I just wrote a new overview of the on disk data structures, which is at
the top of that patch.

More documentation on the internals is up at the bcachefs website:
https://bcachefs.org/Architecture/

I would definitely appreciate feedback on documentation, and in particular what
kind of documentation would be useful to add.
And if anyone can think of anything critical I might have m

---

Regarding upstreaming status, there's not a whole lot left that I can think of
on my end.

As I mentioned at LSF I've pretty much run out of decent reasons for breaking
the on disk format, so that's one of the big motivations for popping up to talk
about upstreaming this thing now. I've been focusing on polishing and bug fixing
for quite awhile at this point - there are lots of features left that would be
really great to have, but they're not blocking people from using it, people are
finding bcachefs useful right now. The code is - alas - not bug free or perfect
yet, but it is definitely more solid and reliable than a filesystem generally
ought to be at this point in its development and deployment.

I have some patches to core code I'll be sending out shortly, but it's mostly
relatively minor stuff - one of the things Ted asked at LSF was if bcachefs was
going to be making new weird assumptions that the VM has to contend with, and
really no - bcachefs is pretty self contained, no weird page forking or anything
like that.

---

Re bcache: one of the things we talked about at LSF (with Hannes in particular)
is that it would be good to provide an upgrade path to bcache users - the bcache
code is not without issues (i.e. lack of big endian support, which is non
trivial to add without on disk format changes - changes I did do for bcachefs).

Bcachefs is partly just a vastly improved version of bcache, minus the block
layer interface and plus a filesystem interface - but the majority of the code
doesn't know or care about which interface is used, and for most of bcachefs
development I did maintain the bcache block layer interface in parallel with the
filesystem interface.

So providing that upgrade path is one of the goals with upstreaming bcachefs.
How exactly it happens is still undecided, but we've got plenty of options -
since with bcache can detach a cache from a backing device and use it in
passthrough mode at runtime, we don't actually have to teach bcachefs to read
the bcache on disk format, except for the backing device superblock (which be
really hard).

Kent Overstreet (2):
  bcachefs: On disk data structures
  bcachefs: Ioctl interface

 fs/bcachefs/bcachefs_format.h | 1448 +++++++++++++++++++++++++++++++++
 fs/bcachefs/bcachefs_ioctl.h  |  182 +++++
 2 files changed, 1630 insertions(+)
 create mode 100644 fs/bcachefs/bcachefs_format.h
 create mode 100644 fs/bcachefs/bcachefs_ioctl.h

-- 
2.17.0

             reply	other threads:[~2018-05-08 22:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-08 22:17 Kent Overstreet [this message]
2018-05-08 22:17 ` [PATCH 1/2] bcachefs: On disk data structures Kent Overstreet
2018-05-11  8:32   ` Dave Chinner
2018-05-11 22:04     ` Kent Overstreet
2018-05-13 20:30   ` Randy Dunlap
2018-05-13 22:29     ` Kent Overstreet
2018-05-13 22:49       ` Randy Dunlap
2018-05-08 22:18 ` [PATCH 2/2] bcachefs: Ioctl interface 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=20180508221800.2642-1-kent.overstreet@gmail.com \
    --to=kent.overstreet@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=hare@suse.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH 0/2] bcachefs: on disk data structures, ioctl interface - review requested for upstreaming' \
    /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

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).