Date: Wed, 7 Apr 2021 13:06:14 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Scott Bennett <bennett@sdf.org>, freebsd-stable@freebsd.org, emaste@freebsd.org Subject: Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users? Message-ID: <fd70f05f-8cee-2057-6398-e83b7da9b842@grosbein.net> In-Reply-To: <202104070549.1375nKJm003266@sdf.org> References: <202104070549.1375nKJm003266@sdf.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd70f05f-8cee-2057-6398-e83b7da9b842>