Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: lvm on raidframe rcorder

On Tue, Oct 05, 2010 at 03:21:32AM +1100, matthew green wrote:
> > I find this kind of duplication of function in our kernel highly
> > objectionable (lvm mirroring should not be *added*, ccd mirroring should,
> > rather, be *removed*).
> our lvm support means we can read more linux disks.
> that isn't duplicate functionality.

If you handwave away the minor fact that there will be three separate
copies of the underlying block mirroring code present in the system, sure,
there's no duplication.  Otherwise you've just basically moved the goal
posts to where the ball happened to land.

It's fine to plan to add functionality while avoiding or eliminating
duplication in the back end.  But we've had dmover in the system for
a decade and nothing's ever been hooked up to it; similarly, we've had
RAIDframe in the system for a very long time and nobody's ever found a
way to teach it to handle the ccd stripe or mirror formats, so we retain
full duplication of functionality there.

I conclude that any plan that doesn't _start with_ converting the
existing frontends to backend functionality _X_ to use the new proposed
generic backend, and then _end with_ adding a new frontend that uses
the new proposed generic backend is likely to just leave us with one
additional implementation of backend and frontend both, cluttering up
the system more and more over time.

Home | Main Index | Thread Index | Old Index