On Fri, 26 Aug 2016, Christopher James Halse Rogers wrote: > > > On Thu, Aug 25, 2016 at 10:11 PM, Marcin Mirosław <marcin@xxxxxxxx> wrote: > > W dniu 25.08.2016 o 13:09, Christopher James Halse Rogers pisze: > > > > > > > > > On Thu, Aug 25, 2016 at 7:21 PM, Marcin MirosÅ‚aw <marcin@xxxxxxxx> wrote: > > > > W dniu 25.08.2016 o 02:03, Christopher James Halse Rogers pisze: > > > > > > > > Hi! > > > > > > > > > On Thu, Aug 25, 2016 at 7:21 AM, marcin@xxxxxxxx wrote: > > > > [...] > > > > > > Does it means that cache is unavailable and only tiering will be > > > > > > in > > > > > > bcachefs? > > > > > > And... How to mount tiered FS? When I pass one device in mount > > > > > > I'm > > > > > > getting: > > > > > > bcache: bch_open_as_blockdevs() register_cache_set err > > > > > > insufficient > > > > > > devices > > > > > > > > > > Tiering gets you all the advantages of caching, plus you can (with > > > > > some > > > > > effort) have the combined filesystem size be the sum of the SSD + > > > > > HDD > > > > > capacities, rather than the capacity be determined solely by the > > > > > capacity of the slow tier (this is not currently the case for > > > > > bcachefs). > > > > > > > > I think that cacheing has at least such advantages over tiering: > > > > - allow fast read and write to files compressed with slow alghoritm > > > > (gzip) > > > > > > I think this is getting into ā€œwhat should we call this thingā€? > > > arguments. A naive cache is just going to promote the gzipped data to > > > the fast storage. On the other end, there's nothing much preventing a > > > sophisticated tiering system from compressing/decompressing as a part of > > > tier demotion/promotion. > > > > When (de|re)compressing would be part of demotion or promotion then I > > agree, cache device doesn't have advantages. > > You also don't get (de|re)compression for free in a caching strategy depending > on where you put your cache. For example, a traditional bcache cache backing a > compressed filesystem will only ever see compressed data. Nor crypto. Best to compress->encrypt->store. -- Eric Wheeler > > > > > > > - can be optimized for using SSD drives > > > > > > It's not clear to me how? Tiering and caching are doing the same sort of > > > things. > > I don't know how bcachefs handle SSD drives. SSD are faster in > > sequential write, I'm not sure if it could be achieved using tier > > device. Using cache device on disk format can be different than using in > > bcachefs and can turn random writes into sequential writes. > > I believe you mean *HDDs* are faster in sequential write? This is exactly what > tiering gets you - all writes go to the fast, SSD storage¹, and then data are > migrated off to the slower HDD in big, sequential chunks. > > ¹: Indeed, IIRC this is the only dataloss bug I've found in bcachefs - I wrote > too much data too fast, the migration from tier 0 to tier 1 couldn't keep up, > and tier 0 filled up to the point where it could no longer write necessary > journal entries, resulting in the filesystem being unmountable. > > -- > 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 > >
