From: Mike Snitzer <snitzer@redhat.com>
To: "Olivier B." <dm.list@daevel.fr>
Cc: Heinz Mauelshagen <heinzm@redhat.com>,
dm-devel@redhat.com, Ming Zhao <mingzhao99th@gmail.com>
Subject: Re: dm-cache module
Date: Sat, 20 Mar 2010 23:37:04 -0400 [thread overview]
Message-ID: <20100321033704.GA6448@redhat.com> (raw)
In-Reply-To: <4BA5623F.8040502@daevel.fr>
On Sat, Mar 20 2010 at 8:03pm -0400,
Olivier B. <dm.list@daevel.fr> wrote:
> Hi,
>
> I'm looking at the dm-cache module from Ming Zhao (
> http://users.cis.fiu.edu/~zhaom/dmcache/index.html ), and would like
> to know if there is a problem to include it upstream.
>
> It looks stable for a while, and some people seem to use it in production.
Such a DM target would be quite useful to have upstream given how
prevalent SSDs have become.
Other work has been a priority but a caching DM target is definitely on
the TODO. If others can help take steps to make a robust caching DM
target a reality then we should be able to get an implementation
upstream sooner rather than later.
Just curious: where have you gotten this insight about dm-cache being
stable and used in production? That should help dm-cache's cause if it
is submitted for review.
Seems Ming posted dm-cache to dm-devel (as a large monolithic patch) on
8/24/07.
dm-cache would need to be rebased to the latest upstream kernel.org
kernel (e.g. Linux >= 2.6.34-rc1).
Ideally dm-cache would be resubmitted to dm-devel incrementally such
that basic infrastructure is introduced in early patches and more
advanced capabilities (e.g. writeback) follow in later patches. Each
patch should have a corresponding patch header the documents what the
patch provides.
Writeback support is arguably the most useful aspect of a caching DM
target so emphasis must be placed on its review/implementation. Using
SSD as a persistent writeback cache should afford us much more fault
tolerance in the face of system crashes during writeback to the slower
media.
I know Heinz has taken steps to implement a caching DM target. So
reconciling dm-cache's design and implementation with what Heinz has
would be a worthwhile component of the dm-cache review (assuming Heinz's
implementation is also posted for review).
Mike
next prev parent reply other threads:[~2010-03-21 3:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-21 0:03 dm-cache module Olivier B.
2010-03-21 3:37 ` Mike Snitzer [this message]
2010-03-21 10:35 ` Olivier B.
[not found] ` <15606e421003202156n21de56a6n868f84bf737cce51@mail.gmail.com>
2010-03-22 15:05 ` Heinz Mauelshagen
2010-04-28 1:33 ` Olivier B.
2010-04-28 8:21 ` Heinz Mauelshagen
2010-04-28 14:02 ` Heinz Mauelshagen
2011-06-03 19:16 ` Phillip Susi
2011-06-06 10:06 ` Heinz Mauelshagen
2012-12-11 21:49 ` Phillip Susi
2012-12-11 21:56 ` Alasdair G Kergon
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=20100321033704.GA6448@redhat.com \
--to=snitzer@redhat.com \
--cc=dm-devel@redhat.com \
--cc=dm.list@daevel.fr \
--cc=heinzm@redhat.com \
--cc=mingzhao99th@gmail.com \
/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.