> 2020-10-24 16:41 GMT+02:00 Stefan Sperling <s...@stsp.name>: > > On Sat, Oct 24, 2020 at 04:11:00PM +0200, Filippo Valsorda wrote: > > > Fair enough, but "there's no auto-assembly and it's inefficient and > > > nothing stops you from messing with the intermediate discipline" is a > > > different kind of not supported than "you should expect kernel panics". > > > > > > If the latter is the case, maybe it should be documented in the > > > softraid(4) CAVEATS, as it breaks the sd(4) abstraction. > > > > Neither Joel's mail nor the word "unsupported" imply a promise > > that it will work without auto-assembly and with inefficient i/o. > > > > Unsupported means unsupported. We don't need to list any reasons > > for this in user-facing documentation. > > I'm not suggesting justifying why, I am saying that softraid(4) is > documented to assemble sd(4) devices into sd(4) devices. If it's > actually "sd(4) devices that are not themselves softraid(4) backed", > that would be worth documenting as it breaks the sd(4) abstraction. > > Said another way, how was I supposed to find out this is unsupported? > It's not like "a mirrored full-disk encrypted device" is an exotic > configuration that would give me pause.
It's documented in the FAQ: > Note that "stacking" softraid modes (mirrored drives and encryption, > for example) is not supported at this time https://www.openbsd.org/faq/faq14.html#softraidFDE
