linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <jason@warr.net>
To: greg@enjellic.com
Cc: paz@navixia.com, linux-bcache@vger.kernel.org,
	scst-devel@lists.sourceforge.net
Subject: Re: How important is bcache cache device in write-thru mode? (was Tiered bcache)
Date: Tue, 28 Jan 2014 18:06:50 +0000 (UTC)	[thread overview]
Message-ID: <213734143.48979.1390932410356.JavaMail.mail@webmail05> (raw)
In-Reply-To: 201401281420.s0SEK0sb008045@wind.enjellic.com


on Jan 28, 2014, Dr. Greg Wettstein <greg@wind.enjellic.com> wrote:
>
>The goal for this driver is a block based interface to RAM for use as
>a cache set for bcache. Since it sits directly on the physical
>hugepage allocator and associated page magazine the block devices can
>be dynamically configured, unlike the current RAM based block device,
>which also has the disadvantage of being implemented on top of page
>cache. None of this should be construed as a gripe against the Linux
>VM but obviously one does not want memory pressure to start driving a
>high speed cache store out onto disk.

Thank you.  In my opinion a dynamic ram disk is one of the few pieces still needed in the block device layer.  I would be happy to help beat the crap out of it!
 
Any thoughts on this driver making use of the DM or MD framework?  Obviously your not going to have data persist across a reboot but do you know how you will handle boot time configuration on a device(s) that you want to come back without manual or scripted intervention?

>
>This model is obviously dependent on solid behavior of bcache in
>write-through mode. We are testing aggressively against 3.10.x and
>haven't tipped it over it but we will turn up the pressure on that and
>see if it gives. I'm pretty confident there is enough community and
>commercial interest in all this to get the bugs beaten out pretty
>thoroughly, provided people report them back.... :-)
>
>We will copy both the bcache and SCST lists when we have something up
>on the FTP site as it would seem to be of interest to both
>communities.
>
>> - Patrick -
>
>Have a good week.
>
>Greg
>
>}-- End of excerpt from Patrick Zwahlen
>
>As always,
>Greg Wettstein, Ph.D. Enjellic Systems Development, LLC.
>4206 N. 19th Ave. Specializing in information infra-structure
>Fargo, ND 58102 development.
>PH: 701-281-1686
>FAX: 701-281-3949 EMAIL: greg@enjellic.com
>------------------------------------------------------------------------------
>"Heaven goes by favor. If it went by merit, you would stay out and your
> dog would go in."
> -- Mark Twain
>--
>To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
 

  parent reply	other threads:[~2014-01-28 18:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <paz@navixia.com>
2014-01-28 14:20 ` How important is bcache cache device in write-thru mode? (was Re: Tiered bcache) Dr. Greg Wettstein
2014-01-28 15:45   ` [Scst-devel] " matthew patton
2014-01-28 18:06   ` jason [this message]
2014-01-28 22:21   ` Patrick Zwahlen

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=213734143.48979.1390932410356.JavaMail.mail@webmail05 \
    --to=jason@warr.net \
    --cc=greg@enjellic.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=paz@navixia.com \
    --cc=scst-devel@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).