Re: NetBSD's LVM works great for me

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Mar 22,  9:08am, Swift Griggs wrote:

     I'm way behind on my NetBSD mail and I've noticed that a few
other people have commented, but I'll mention some stuff that I
haven't seen yet.

} I've been using LVM under NetBSD now in 7.0 since the release. I have 
} found it to be remarkably stable for such a newly implemented set of 
} features. Maybe I just haven't been doing enough to beat on it.

     As noted, it's been around for about 7.5 years and the first
release it appeared in was 6.0.  I'm using it on a numbr of systems
running 6.x era kernels without issue.  The big problem is that
pretty much nothing significant was done since it first appeared.

     Some comments on the implementation.  First is that the
user-level command, lvm(8), was simply imported from the Linux
sources.  In other words, it is exactly what you have been seeing
on Linux systems for some time.  The kernel part is a rewrite from
scratch (GPL code is not allowed in the kernel).  The kernel part
is called the device-mapper or dm for short.  See "man 4 dm" for
more information.  That part was written as a GSOC project.  It
consists of a base part for the infrastructure plus various modules
to implement the various back ends.

} How possible/likely is it that NetBSD's LVM could get:
} 
}    * LVM caching devices ala Linux. RHEL 7.1 intro'd this and it works
}      quite well. Ie.. using a fast disk to cache & front-end slower ones.
}      This way you can get a ZIL-like feature without having ZFS or any
}      specific file system.
} 
}    * Some kind of DRBD-async-proxy-alike feature. I know this is the killer
}      pay-only feature in DRBD. It's also extremely wonderful. I'm probably
}      dreaming, but this would be awesome. It could be implemented in LVM
}      ala VxVM's "Volume Replicator" (which is also a "pay us a bit more
}      because we know you want this awesome feature"). It could also be done
}      standalone in a separate subsystem.

     To get new things, you would likely need to import a newer
version of the LVM tools (which should probably be done anyways,
if for no other reason to properly handle multi-terabyte drives).
Then you would need to write new backend modules for the device
mapper.

}-- End of excerpt from Swift Griggs