Re: How to create bcachefs?

[Christopher James Halse Rogers <chris@cooperteam.net>]

On Thu, Aug 25, 2016 at 10:11 PM, Marcin Mirosław <marcin@mejor.pl> 
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@mejor.pl> 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@mejor.pl 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.

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