Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
Eugene Grosbein
eugen at grosbein.net
Wed Apr 7 06:06:34 UTC 2021
07.04.2021 12:49, Scott Bennett via freebsd-stable wrote:
> At least w.r.t. gvinum's raid5, I can attest that the kernel panics
> are real. Before settling on ZFS raidz2 for my largest storage pool, I
> experimented with gstripe(8), gmirror(8), graid3(8), and graid5(8) (from
> sysutils/graid5). All worked reasonably well, except for one operation,
> namely, "stop". Most/all such devices cannot actually be stopped because
> a stopped device does not *stay* stopped. As soon as the GEOM device
> node is destroyed, all disks are retasted, their labels, if any, are
> recognized, and their corresponding device nodes are recreated and placed
> back on line. :-( All of this happens too quickly for even a series of
> commands entered on one line to be able to unload the kernel module for
> the device node type in question, so there is no practical way to stop
> such a device once it has been started.
In fact, you can disable re-tasting with sysctl kern.geom.notaste=1,
stop an GEOM, clear its lables and re-enable tasting setting kern.geom.notaste=0 back.
> A special note is needed here regarding gcache(8) and graid3(8). The
> documentation of gcache parameters for sector size for physical devices
> and gcache logical devices is very unclear, such that a user must have the
> device nodes and space on them available to create test cases and do so,
> whereas a properly documented gcache(8) would obviate the need to set up
> such experiments. There is similar lack of clarity in various size
> specifications for blocks, sectors, records, etc. in many of the man pages
> for native GEOM commands.
I found gcache(8) very nice at first, it really boosts UFS performance provided
you have extra RAM to dedicate to its cache. gcache can be stacked with gmirror etc.
but I found it guilty to some obscure UFS-related panics. It seems there were races or something.
No data loss, though as it is intended to be transparent for writing.
I was forced to stop using gcache for sake of stability and it's a shame.
For example, dump(8) speed-up due to gcache was 2x at least with big cache
comparing to dump -C32 without gcache.
More information about the freebsd-stable
mailing list