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 think. > 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. -- CraigReceived on Fri Aug 06 2004 - 11:38:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:05 UTC