craig at xfoil.gank.org
Fri Aug 6 06:38:08 PDT 2004
On Thu, Aug 05, 2004 at 11:06:16PM -0400, Paul Mather wrote:
> The only time I've had a problem is when I last built a kernel (today,
> actually) and forgot to build geom_vinum.ko manually. Needless to say,
> the next boot failed to find my root partition due to the missing kernel
> module. Luckily, rebooting using /boot/kernel.old allowed me to build
> and install geom_vinum.ko and boot my new kernel successfully.
It would be nice if geom_vinum and gvinum could be hooked up to the
build. There are quite a few people using them now and they seem to be
"usable enough" (for CURRENT anyway). I don't think it would hurt
anything as the user would still have to configure it manually -- it's
not going to start stealing drives away from non-GEOM vinum I don't
> I mentioned on freebsd-current that round-robin reads don't seem to be
> supported by geom_vinum, yet. (Lukas confirmed this is yet to be
> done.) In my system, all reads are from one drive of my mirror, unlike
> with the old vinum. Perhaps this is partially the cause of the relative
> slowness you're seeing?
I wonder how this is handled in the RAID5 case, where you don't really
have a choice. You either have to round robin read, or read all the
drives and suffer the parity calculation penalty.
/off to check the source...
> It'd be great to see GEOM vinum go into 5.3, and hence be adopted for
> 5-STABLE. Great work, Lukas!
Agreed, I'm quite happy that I can swap over vinum again without md(4)
hacks. Straight GEOM classes may eventually be more flexible, but for
now vinum is still the simplest way to get volume management. Having a
clean upgrade path from 4.x is a very good thing too.
More information about the freebsd-current