All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Jason Warr <jason-/cow75dQlsI@public.gmane.org>
Cc: Joseph Glanville
	<joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org>,
	Roy Sigurd Karlsbakk
	<roy-ooPBL11mRiZbRRN4PJnoQQ@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 12:40:14 -0800	[thread overview]
Message-ID: <20130219204014.GK27179@google.com> (raw)
In-Reply-To: <5123B976.6050400-/cow75dQlsI@public.gmane.org>

On Tue, Feb 19, 2013 at 11:42:14AM -0600, Jason Warr wrote:
> 
> 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.

Yeah, that idea's been kicked around before. A couple people have said
they were going to work on it, but nothing's happened.

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

You actually don't have to switch out of writeback mode to safely detach
- if you detach in writeback mode, it detaches as soon as it's finished
flushing all the dirty data.

  parent reply	other threads:[~2013-02-19 20:40 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
     [not found]               ` <5123B976.6050400-/cow75dQlsI@public.gmane.org>
2013-02-19 20:40                 ` Kent Overstreet [this message]
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=20130219204014.GK27179@google.com \
    --to=koverstreet-hpiqsd4aklfqt0dzr+alfa@public.gmane.org \
    --cc=andrew-3e6jenk95VYpDvLZ8AWkcaVXKuFTiq87@public.gmane.org \
    --cc=jason-/cow75dQlsI@public.gmane.org \
    --cc=joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@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 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.