On Tue, Sep 17 2013 at 8:41am -0400, Akira Hayakawa <ruby.wktk@xxxxxxxxx> wrote: > Mike, > > First, thank you for your commenting. > I was looking forward to your comments. > > > I suppose you are sensing some "smell" in my design. > You are worrying that dm-writeboost will not only confuse users > but also fall into worst situation of giving up backward-compatibility > after merging into tree. > > That dm-writeboost's design is too eccentric as a DM target makes you so. > > That you said > > determines whether a device needs formatting, etc. Otherwise I cannot > > see how you can properly stack DM devices on writeboost devices > > (suspend+resume become tediously different) > is a proof of smell. > > Alasdair also said > > 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. > > and > > Mikulas said > > Another idea: > > > > Make the interface of dm-lc (the arguments to constructor, messages and > > the status line) the same as dm-cache, so that they can be driven by the > > same userspace code. > Though I guess this is going too far > since dm-writeboost and dm-cache are the different things > designing them similar definitely makes sense. > > are also sensing of smell. > > > I am afraid so I am and > I am thinking of re-designing dm-writeboost > at the fundamental architectural level. > The interfaces will be similar to that of dm-cache as a result. > > This will be a really a BIG change. > > > Probably best for you to publish the dm-writeboost code a git repo on > > github.com or the like. I just don't see what benefit there is to > > putting code like this in staging. Users already need considerable > > userspace tools and infrastructure will also be changing in the > > near-term (e.g. the migration daemon). > Yes, I agree with that regarding the current implementation. > I withdraw from the proposal for staging. > I am really sorry for Greg and others caring about dm-writeboost. > But I will be back after re-designing. OK, appreciate your willingness to rework this. > staging means lot to get 3rd party users is for sure. We don't need to go through staging. If the dm-writeboost target is designed well and provides a tangible benefit it doesn't need wide-spread users as justification for going in. The users will come if it is implemented well. > Simplify the design and > make it more possible to maintain the target > for the future is what I fully agree with. > Being adhere to cache-sharing by > risking the future maintainability doesn't pay. > Re-designing the dm-writeboost resemble to dm-cache > is a leading candidate of course. Simplifying the code is certainly desirable. So dropping the sharing sounds like a step in the right direction. Plus you can share the cache by layering multiple linear devices ontop of the dm-writeboost device. Also managing dm-writeboost devices with lvm2 is a priority, so any interface similarities dm-writeboost has with dm-cache will be beneficial. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
