linux-kernel - Re: staging: Add dm-writeboost

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Sep 2013 21:43:18 +0900
From:	Akira Hayakawa <ruby.wktk@...il.com>
To:	snitzer@...hat.com
CC:	gregkh@...uxfoundation.org, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org, dm-devel@...hat.com,
	cesarb@...arb.net, joe@...ches.com, akpm@...ux-foundation.org,
	agk@...hat.com, m.chehab@...sung.com
Subject: Re: staging: Add dm-writeboost

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/