Re: [ANNOUNCE] bcachefs!

[Kent Overstreet <kent.overstreet@gmail.com>]

On Tue, Jul 21, 2015 at 04:53:44PM -0500, Jason Warr wrote:
> 
> 
> On 7/21/2015 1:37 PM, David Mohr wrote:
> >On 2015-07-13 18:58, Kent Overstreet wrote:
> >>Short announcement, because I'm in the process of moving - but I wanted
> >>to get
> >>this out there because the code is up and I think it's reasonably stable
> >>right
> >>now.
> >>
> >>Bcachefs is a posix filesystem that I've been working towards for -
> >>well, quite
> >>awhile now: it's intended as a competitor/replacement for
> >>ext4/xfs/btrfs.
> >>
> >>Current features
> >> - multiple devices
> >> - replication
> >> - tiering
> >> - data checksumming and compression (zlib only; also the code doesn't
> >>work with
> >>   tiering yet)
> >> - most of the normal posix fs features (no fallocate or quotas yet)
> >>
> >>Planned features:
> >> - snapshots!
> >> - erasure coding
> >> - more
> >>
> >>There will be a longer announcement on LKML/linux-fs in the near future
> >>(after
> >>I'm finished moving) - but I'd like to get it a bit more testing from a
> >>wider
> >>audience first, if possible.
> >
> >Hi Kent,
> >
> >one quick question about the roadmap at this point: As far as I understand
> >bcachefs basically integrates bcache features directly in the filesystem.
> >So does this deprecate bcache itself in your opinion? Bcache is obviously
> >still useful for other FS, but I just want to know how things will get
> >maintained in the future.
> >
> It would be rather disappointing if this were the case.  bcache is quite
> useful for backing block devices that have no local filesystem, such as
> devices exported via iSCSI, devices used directly by VMs, etc...

 - bcachefs/bcache2 getting merged is a _long_ way off, and when it does it's
   going to be more of an ext2/ext3 thing - the existing upstream bcache version
   will stay there for the foreseeable future.

 - bcachefs/bcache2 still has all the same functionality bcache has for caching
   other block devices, and exporting thin provisioned block devices - that
   functionality won't be going away any time soon, if ever - so you'll be able
   to migrate to the new bcache code and on disk format without changing
   anything about how you use it.
 
   The "backing device/cached dev" path _might_ eventually get deprecated in
   favor of having bcache manage all the block devices directly and export thin
   provisioned block devices - this is the existing "flash_vol_create"
   functionality.

   Reason being the thin provisioned/fully bcache managed block devices path is
   quite a bit simpler and diverges less from the functionality bcachefs uses -
   and also cache coherency is fundamentally easier with bcache managing all the
   storage so performance should be better too.

   However, if the backing device functionality ever gets removed it's a _long_
   ways off, and I'll be asking for user feedback and making sure the thin
   provisioned/bcache managed block devices functionality works for everyone
   first.