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