Hi Kent, On Thu, 2015-08-20 at 21:25 -0800, Kent Overstreet wrote: > For those who haven't kept up with bcache, the bcache codebase has been > evolving/metastasizing into a full blown, general purpose posix filesystem - a > modern COW filesystem with checksumming, compression, multiple devices, caching, > and eventually snapshots and all kinds of other nifty features. > > "Yet another new filesystem? Why?" > > Well, years ago (going back to when I was still at Google), I and the other > people working on bcache realized that what we were working on was, almost by > accident, a good chunk of the functionality of a full blown filesystem - and > there was a really clean and elegant design to be had there if we took it and > ran with it. And a fast one - the main goal of bcachefs to match ext4 and xfs on > performance and reliability, but with the features of btrfs/zfs. > <snip> > > PLANNED FEATURES: > - snapshots (might start on this soon) > - erasure coding What erasure coding scheme(s) do you like to use? > - native support for SMR drives, raw flash How do you imagine SMR drives support? How do you feel about libzbc [1] using for SMR drives support? I am not very familiar with bcachefs architecture yet. But I suppose that maybe libzbc model can be useful for SMR drives support on bcachefs side. Anyway, it makes sense to discuss proper model. How do you imagine raw flash support in bcachefs architecture? Frankly speaking, I am implementing NAND flash oriented file system. But this project is proprietary yet and I can't share any details. However, currently, I've implemented NAND flash related approaches in my file system only. So, maybe, it make sense to consider some joint variant of bcachefs and implementation on my side for NAND flash support. I need to be more familiar with bcachefs architecture for such decision. But, unfortunately, I suspect that it can be not so easy to support raw flash for bcachefs. Of course, I can be wrong. [1] https://github.com/hgst/libzbc Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
