On Wed, Jan 07, 2015 at 09:41:19AM -0800, Jianjian Huo wrote: > Hi Kent, > > On Tue, Jan 6, 2015 at 5:48 PM, Kent Overstreet <kmo@xxxxxxxxxxxxx> wrote: > > > > On Tue, Jan 06, 2015 at 11:18:10PM +0100, Rolf Fokkens wrote: > > > On 01/05/2015 08:47 AM, Slava Pestov wrote: > > > >The plan is to incrementally backport bug fixes and optimizations from > > > >bcache-dev to upstream for the foreseeable future. > > > I assume (hope) this won't break bcache w.r.t. the current block device > > > layout? > > > >The development branch is going through major changes to support > > > >dynamically adding/removing cache devices > > > Sound nices, that creates great flexibility. Does this also introduce the > > > option of storing mirrored writeback data, while storing single copy read > > > (cached) data (when having multiple SSD's as a cache)? > > > > Yup, and a lot more. > > > > > >and storing data in the btree instead of using it as a cache, enabling > > > >usage without any backing devices. > > > The needs some explanation. I assume you mean it operates as writeback bache > > > that never flushes. If that's correct, I can only imagine it's useful when > > > initially using it. And in that case seems a kind of a time bomb, because > > > when it's "full" (and there's still no backing device)... what happens then? > > > > What Slava is alluding to is that bcache is becoming a full posix filesystem - I > > was actually demoing it... nearly a year ago, I think. With eventual feature > > parity with btrfs and much, much better performance. > > > > btrfs use COW b-tree shadowing to support snapshots and clones, what > approach will this new bcache FS use to support those features? bcache has always been COW for data, and it supports copy offload (i.e. btrfs reflink) today via just multiple extents pointing to the same data. I'll write up the plan for snapshots at some point, it's quite different from the btrfs approach. > And will this new FS continue to use 2MB buckets without random writes > in them? if that's the case, when this new FS is used on SSDs only, I > guess FS GC has to be turned on for all buckets to reclaim free space. > Since a lot of SSDs use parallel writes, some use compression, it's > not possible to align one logical 2MB bucket at FS level to one single > physical NAND block, then GC will be performed twice for one dirty > bucket at different levels, so SSD life will be cut in half in the > worst case? Yeah that is a potential issue, for SSDs what we really want is to get raw access to flash and have bcache be the FTL. Even if that doesn't happen there are things we can do to mitigate though, suffice it to say this issue has been discussed a lot :) -- 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
