From: Akira Hayakawa <ruby.wktk@gmail.com>
To: snitzer@redhat.com
Cc: gregkh@linuxfoundation.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org, dm-devel@redhat.com,
cesarb@cesarb.net, joe@perches.com, akpm@linux-foundation.org,
agk@redhat.com, m.chehab@samsung.com
Subject: Re: staging: Add dm-writeboost
Date: Tue, 17 Sep 2013 21:43:18 +0900 [thread overview]
Message-ID: <52384E66.6050101@gmail.com> (raw)
In-Reply-To: <20130916215357.GA5015@redhat.com>
Hi, Mike
There are two designs in my mind
regarding the formatting cache.
You said
> administer the writeboost devices. There is no need for this. Just
> have a normal DM target whose .ctr takes care of validation and
> determines whether a device needs formatting, etc.
makes me wonder how I format the cache device.
There are two choices for formatting cache and create a writeboost device
standing on the point of removing writeboost-mgr existing in the current design.
I will explain them from how the interface will look like.
(1) dmsetup create myDevice ... "... $backing_path $cache_path"
which will returns error if the superblock of the given cache device
is invalid and needs formatting.
And then the user formats the cache device by some userland tool.
(2) dmsetup create myDevice ... "... $backing_path $cache_path $do_format"
which also returns error if the superblock of the given cache device
is invalid and needs formatting when $do_format is 0.
And then user formats the cache device by setting $do_format to 1 and try again.
There pros and cons about the design tradeoffs:
- (i) (1) is simpler. do_format parameter in (2) doesn't seem to be sane.
(1) is like the interfaces of filesystems where dmsetup create is like mounting a filesystem.
- (ii) (2) can implement everything in kernel. It can gather all the information
about how the superblock in one place, kernel code.
Excuse for the current design:
- The reason I design writeboost-mgr is almost regarding (ii) above.
writeboost-mgr has a message "format_cache_device" and
writeboost-format-cache userland command kicks the message to format cache.
- writeboost-mgr has also a message "resume_cache"
that validates and builds a in-memory structure according to the cache binding to given $cache_id
and user later dmsetup create the writeboost device with the $cache_id.
However, resuming the cache metadata should be done under .ctr like dm-cache does
and should not relate LV to create and cache by external cache_id
is what I realized by looking at the code of dm-cache which
calls dm_cache_metadata_open() routines under .ctr .
I don't know why I should not do this it is nicer to trust DM guys in RedHat on this point.
writeboost-mgr is something like smell of over-engineering but
is useful for simplifying the design for above reasons.
Which do you think better?
Akira
next prev parent reply other threads:[~2013-09-17 12:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-01 11:10 [PATCH] staging: Add dm-writeboost Akira Hayakawa
2013-09-16 21:53 ` Mike Snitzer
2013-09-16 22:49 ` Dan Carpenter
2013-09-17 12:41 ` Akira Hayakawa
2013-09-17 20:18 ` Mike Snitzer
2013-09-17 12:43 ` Akira Hayakawa [this message]
2013-09-17 20:59 ` Mike Snitzer
2013-09-22 0:09 ` Reworking dm-writeboost [was: Re: staging: Add dm-writeboost] Akira Hayakawa
2013-09-24 12:20 ` Akira Hayakawa
2013-09-25 17:37 ` Mike Snitzer
2013-09-26 1:42 ` Akira Hayakawa
2013-09-26 1:47 ` Akira Hayakawa
2013-09-27 18:35 ` Mike Snitzer
2013-09-28 11:29 ` Akira Hayakawa
2013-09-25 23:03 ` Greg KH
2013-09-26 3:43 ` Dave Chinner
2013-10-01 8:26 ` Joe Thornber
2013-10-03 0:01 ` [dm-devel] " Mikulas Patocka
2013-10-04 2:04 ` Dave Chinner
2013-10-05 7:51 ` Akira Hayakawa
2013-10-07 23:43 ` Dave Chinner
2013-10-08 9:41 ` Christoph Hellwig
2013-10-08 10:37 ` Akira Hayakawa
[not found] ` <20131008152924.GA3644@redhat.com>
2013-10-09 1:07 ` Akira Hayakawa
2013-10-08 10:57 ` [dm-devel] " Akira Hayakawa
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=52384E66.6050101@gmail.com \
--to=ruby.wktk@gmail.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cesarb@cesarb.net \
--cc=devel@driverdev.osuosl.org \
--cc=dm-devel@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=snitzer@redhat.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 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).