On 7/24/2015 2:32 PM, Kent Overstreet wrote:
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.
As long as we get the same basic functionality in addition to the
filesystem layer, it sounds like you plan on that, I'm happy.
Thank you for addressing this.
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
