Re: [dm-devel] [RFC] dm-writeboost: plan to go to staging

[Akira Hayakawa <ruby.wktk@gmail.com>]

Thanks, Alasdair.

I will reply to some of your comments
that is not answered up to now.

> The documentation file will eventually need rewriting to follow the same
> format as the other targets recently added to the kernel.  We document
> the kernel interface rather than any particular userspace tools, which
> just have the status of convenient examples.
dm-writeboost can be used by kicking kernel interfaces but
it is not recommended.
My userspace tools take care of all the
implications in using the kernel interfaces.
The fact dm-writeboost supports shared-caching and
write-back caching with auto-modulated migration
puts the interfaces and implementations under some constraints.
That's simply a tradeoff.

OK, I will document the kernel interfaces
and also mention the userspace tools.

> (Your code also needs many more comments inline to explain what it does
> and how it works.)
Comments are substantially noise is my philosophy.
I will add comments with given feedback clearly mentioning
what is clear and what is not clear about the source code.
Even in that case,
I'd better polish the code rather than write comments.

> Another little thing I noticed: look into using something like
> __dm_bless_for_disk() for your metadata and clearly segregate your
> on-disk structures and document the layout.
I couldn't understand what is __dm_bless_for_disk() for.
What does the word "bless" mean in this context?

By the way,
dm-cache and dm-writeboost are definitely different in a way that
dm-cache has an another disk for metadata while dm-writeboost doesn't.
dm-writeboost packs metadata and data within a log and
submit it to the cache device like log-structured filesystem.

So, the annotation checks can not be appropriated
to apply to dm-writeboost.

And what about moving these macros to
include/linux/device-mapper.h?

Akira

On 8/29/13 12:30 PM, Alasdair G Kergon wrote:
> On Wed, Aug 28, 2013 at 07:05:55PM -0700, Greg KH wrote:
>> For staging drivers, I need a TODO file that lists
>> what needs to be done to the code to get it into a mergable state for
>> the "real" part of the kernel,
> 
> Two simple requirements before putting your proof-of-concept into staging
> if you want to work that way:
> 
> 1) Drop the major version number to 0.  Version 1 is reserved for
> supported modules.
> 
> 2) Agree a new and meaningful target name with us so you don't have to
> change it later.  "lc" means nothing, I'm afraid.
> 
> Then in general terms, you should continue to compare your device-mapper
> target with the existing targets and where there are differences, either
> change your target to be like something that already exists, or be ready
> to explain why that can't or shouldn't be done.
> 
> In particular, the interface and architecture will need substantial
> changes and working these out should be your highest priority.
> 
> For example, you write:
> 
>   Be careful, you MUST create all the LVs as the destinations of
>   the dirty blocks on the cache device before this operation.  Otherwise,
>   the kernel may crash.
> 
> I read a statement like that as an indication of an interface or
> architectural problem.  The device-mapper approach is to 'design out'
> problems, rather than relying on users not doing bad things.
> Study the existing interfaces used by other targets to understand
> some approaches that proved successful, then decide which ones
> come closest to your needs.
> 
> (Your code also needs many more comments inline to explain what it does
> and how it works.)
> 
> The documentation file will eventually need rewriting to follow the same
> format as the other targets recently added to the kernel.  We document
> the kernel interface rather than any particular userspace tools, which
> just have the status of convenient examples.
> 
> Another little thing I noticed: look into using something like
> __dm_bless_for_disk() for your metadata and clearly segregate your
> on-disk structures and document the layout.
> 
> Alasdair
>