All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Elsayed <eternaleye@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Hybrid Storage proposal
Date: Wed, 20 Feb 2013 22:53:44 -0800	[thread overview]
Message-ID: <kg4g9l$4p8$1@ger.gmane.org> (raw)
In-Reply-To: CA+WRLO8ESSq6NrHOvUTQ3Sm+4RyBmSoU+PZ1wnqxwQBgG04=Tw@mail.gmail.com

Gareth Pye wrote:

> On Thu, Feb 21, 2013 at 3:46 AM, Matias Bjorling <mabj@itu.dk> wrote:
>> Recent development in Linux SSD caches, uses a block IO approach to solve
>> caching. The approach assumes that data is stable on disk and evicts data
>> based on LRU, temparature, etc. This is great for read only IO patterns
>> and in-place writes. However, btrfs uses a copy on write approach, that
>> reduces the benefits of block IO caching. The block caches are unable to
>> track updates (require extensive hints forth and back between the cache
>> layer). Additionally, data and metadata is the same to the block layer.
> 
> 
> Another great reason for this to be implemented in btrfs is that
> knowledge of redundancy can be applied. Chunks that are mirrored
> should be unlikely to need both copies on SSD devices unless they are
> very highly used (probably true for some of the meta data but not for
> data).

On the other hand, there's the option of doing something that bcache has had 
on its roadmap for a while (but I'm not sure was ever implemented) by 
striping clean data and mirroring dirty data across the SSDs. The intent for 
bcache was to maximize both redundancy (for dirty data, which can't be 
regenerated) and space (for clean data, where if you lose some you can just 
shrug and say "oh well") in the case of one SSD failing.

> Conversely there is little benefit to putting one stripe of a
> raid0/5/6 into the SSD device without the rest of that data reaching
> the same level.
> 
> Not that additional reasons to do this work in btrfs were needed it
> does need to be thought about how this implementation interacts with
> those features.
> 

Agreed.


  reply	other threads:[~2013-02-21  6:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20 16:46 Hybrid Storage proposal Matias Bjorling
2013-02-20 19:19 ` Alex Elsayed
2013-02-21  9:25   ` Matias Bjørling
2013-02-21  0:49 ` Gareth Pye
2013-02-21  6:53   ` Alex Elsayed [this message]
2013-02-26 11:04 ` Zhi Yong Wu
2013-02-26 13:08   ` [POSSIBLE SPAM] " Matias Bjørling
2013-02-27 11:50     ` Zhi Yong Wu

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='kg4g9l$4p8$1@ger.gmane.org' \
    --to=eternaleye@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.