Bug 251610 - [patch] rc.d/zpool runs before ada(4) attaches
Summary: [patch] rc.d/zpool runs before ada(4) attaches
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-rc (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-05 17:41 UTC by Harald Schmalzbauer
Modified: 2021-02-20 14:42 UTC (History)
0 users

See Also:


Attachments
extend rc.d/dumpon to check and delay for cam(4) probing (1.63 KB, patch)
2020-12-05 17:41 UTC, Harald Schmalzbauer
no flags Details | Diff
extend rc.d/dumpon to check and delay for cam(4) probing (1.67 KB, patch)
2021-02-15 21:21 UTC, Harald Schmalzbauer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Schmalzbauer 2020-12-05 17:41:18 UTC
Created attachment 220284 [details]
extend rc.d/dumpon to check and delay for cam(4) probing

On systems with root from memory filesystem, and probably also true for nvd(4) backed root systems, rc.d/zpool doesn't work, because at the time it runs, cam(4) is still in state (aprobe) for attached SSDs (850pro in my test case).
I can imagine much slower disks attaching, leading to similar problems for the not so rare cases where root mounts not from md(4).

This affects dumpon and swapon too, which might have even higher impact than zpool!

The attached diff checks the output of camcontrol(8), which is in /sbin on rootfs, without utilizing anything from /usr filesystem.

The overhead should be neglectable on systems not affected, which unconditionally run the check, but it's not expensive considering it's only run once at startup.
Comment 1 Harald Schmalzbauer 2021-02-15 21:21:22 UTC
Created attachment 222477 [details]
extend rc.d/dumpon to check and delay for cam(4) probing

Accidentally found this unresolved PR and noticed, that the patch is outdated.
Here's what enables me to use OpenZFS in production.