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.
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox