From: Christopher James Halse Rogers <chris@cooperteam.net>
To: "Marcin Mirosław" <marcin@mejor.pl>
Cc: linux-bcache@vger.kernel.org
Subject: Re: How to create bcachefs?
Date: Fri, 26 Aug 2016 11:06:50 +1000 [thread overview]
Message-ID: <1472173610.31787.2@mail.cooperteam.net> (raw)
In-Reply-To: <13f3920b-638f-bf04-40ec-7cece2c34b78@mejor.pl>
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.
next prev parent reply other threads:[~2016-08-26 1:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-19 18:07 How to create bcachefs? marcin
2016-08-24 6:52 ` Kent Overstreet
2016-08-24 21:21 ` marcin
2016-08-24 23:12 ` Eric Wheeler
2016-08-24 23:52 ` Kent Overstreet
2016-08-24 23:50 ` Kent Overstreet
2016-08-25 0:03 ` Christopher James Halse Rogers
2016-08-25 9:21 ` Marcin Mirosław
2016-08-25 11:09 ` Christopher James Halse Rogers
2016-08-25 12:11 ` Marcin Mirosław
2016-08-26 1:06 ` Christopher James Halse Rogers [this message]
2016-08-26 1:48 ` Eric Wheeler
2016-08-26 8:23 ` Marcin Mirosław
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1472173610.31787.2@mail.cooperteam.net \
--to=chris@cooperteam.net \
--cc=linux-bcache@vger.kernel.org \
--cc=marcin@mejor.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.