Eugene Grosbein wrote:
> 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.
Thank you for this valuable, but undocumented, workaround! However, it
serves to demonstrate the bugs in gstripe(8), gmirror(8), graid3(8), and
graid5(8), and perhaps a few others, either in the commands themselves, which
do not behave as advertised in their respective man pages or in their man pages
for not correctly documenting the commands' actual behavior.
>
> > 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.
There are other, also undocumented, problems. For example, I played with
gcache(8) for a short time as a method of dividing a ZFS pool into two extents
on a drive in order to place a frequently accessed partition between them. It
worked nicely for a while, but the first time that gcache(8) choked it made a
real mess of the ZFS pool's copy on that drive. As a result I immediately
abandoned that use of gcache(8).
gcache(8) usses two poorly defined sysctl values, kern.geom.cache.used_hi
and kern.geom.cache.used_lo. Its man page shows them with default values, but
neglects to mention whether they are enforced limits or merely sysctl variables
that report current or high and low watermark usages.
>
> 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.
>
I used it to make all accesses to a graid3(8) set of partitions work with
64 KB and 32 KB block sizes for UFS2 efficiency on a graid3(8) device. That use
worked very nicely, but it took some experimentation to figure out how to do it
because the man page is so ambiguous about the gcache command's options and
arguments.
A similar complaint could be leveled at the man pages for gstripe(8),
graid3(8), and graid5(8) w.r.t. their undocumented definitions of stripe size,
sector size, and block size. At present, without reading the command and kernel
source code for each or experimenting extensively, it is difficult to understand
what the commands' options and arguments will do and which combinations of their
numerical values can be valid and accepted.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
