public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Warr <jason-/cow75dQlsI@public.gmane.org>
To: Joseph Glanville
	<joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org>
Cc: Roy Sigurd Karlsbakk
	<roy-ooPBL11mRiZbRRN4PJnoQQ@public.gmane.org>,
	Kent Overstreet
	<koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Andrew Thrift
	<andrew-3e6jenk95VYpDvLZ8AWkcaVXKuFTiq87@public.gmane.org>,
	linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: bcache vs enhanceio?
Date: Tue, 19 Feb 2013 11:42:14 -0600	[thread overview]
Message-ID: <5123B976.6050400@warr.net> (raw)
In-Reply-To: <CAOzFzEj=Gna7AQK9f01i9a64qXw0TFjNPjsEViTRcaLKDdcHpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>


On 02/19/2013 11:17 AM, Joseph Glanville wrote:
> I am not Kent.. but I can answer your questions.
>
> 8<--- snip ---->8
>> A question for Kent, once you have bcache and it's tools built,
>> installed and running, is there anything to stop a user from always
>> tagging devices of whatever type you choose from having the superblock
>> info to accept a cache dynamically?  Example, if I create an MD RAID
>> device and before I pvcreate or anything else with it I prep it for
>> bcache but don't actually attach a cache device, is there any negative
>> effects that can come from that?  Can I then at anytime attach a cache
>> device to it?  I realize that once attached in writeback it becomes
>> non-detachable.  Same question for raw sd devices and LVM volumes.
> In short yes, there are no detrimental effects for having backing
> devices with superblocks that don't have associated cache sets.

That's what I thought.  This could be an argument for integration with
DM or MD.  Up-rev the superblock or metadata version and have the bcache
bits in it by default.

>
> To touch on the second point about writeback - it's not so much that
> it's non-detachable it's that you don't want the backing device to be
> used while the cache is not attached and is dirty (contains unflushed
> data).
>
> You can detach the cache safely from a writeback device by first
> switching the cache to writethrough (or none from memory) and waiting
> for the data to flush to the backing device.
> Once that is done you can either continue to use it in writethrough
> mode or you can detach it completely.
>
:) Typing faster than I am thinking.  I should have said non-detachable
while in writeback mode, or rather while it contains "dirty" blocks.

  parent reply	other threads:[~2013-02-19 17:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130213041453.9D6F6F5149@zimbra.karlsbakk.net>
     [not found] ` <20130213041453.9D6F6F5149-QnAKKd0jTYMSbMbpMVjRk+TW4wlIGRCZ@public.gmane.org>
2013-02-19 12:23   ` bcache vs enhanceio? Roy Sigurd Karlsbakk
2013-02-19 16:41     ` Jason Warr
     [not found]       ` <5123AB2B.9020209-/cow75dQlsI@public.gmane.org>
2013-02-19 17:17         ` Joseph Glanville
     [not found]           ` <CAOzFzEj=Gna7AQK9f01i9a64qXw0TFjNPjsEViTRcaLKDdcHpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-19 17:42             ` Jason Warr [this message]
     [not found]               ` <5123B976.6050400-/cow75dQlsI@public.gmane.org>
2013-02-19 20:40                 ` Kent Overstreet
2013-02-07 21:25 Roy Sigurd Karlsbakk
2013-02-07 23:05 ` Andrew Thrift
     [not found]   ` <5114334D.7040709-3e6jenk95VYpDvLZ8AWkcaVXKuFTiq87@public.gmane.org>
2013-02-12 20:41     ` Roy Sigurd Karlsbakk
2013-02-12 21:56       ` Kent Overstreet
     [not found]         ` <20130212215629.GJ27179-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-02-19 12:48           ` Joseph Glanville
     [not found]             ` <CAOzFzEiLeW=nvuwcrVrs2xO__92ze7b6BDt8MkAkaNctuSR9Vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-19 15:33               ` Joseph Glanville
2013-02-19 16:47               ` Jason Warr

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=5123B976.6050400@warr.net \
    --to=jason-/cow75dqlsi@public.gmane.org \
    --cc=andrew-3e6jenk95VYpDvLZ8AWkcaVXKuFTiq87@public.gmane.org \
    --cc=joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org \
    --cc=koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=roy-ooPBL11mRiZbRRN4PJnoQQ@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox