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 [off-list ref] wrote:

quoted

W dniu 25.08.2016 o 02:03, Christopher James Halse Rogers pisze:

Hi!

quoted

 On Thu, Aug 25, 2016 at 7:21 AM, marcin@mejor.pl wrote:

[...]

quoted

quoted

 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.

quoted

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

Marcin