Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Dec 2020 18:46:22 +0100
From:      Harry Schmalzbauer <freebsd@omnilan.de>
To:        Ian Lepore <ian@freebsd.org>, Ronald Klop <ronald-lists@klop.ws>, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: rc.d/zpool runs before ada(4) attaches
Message-ID:  <a43531d6-8828-89aa-4d6d-6bcb9fb75cfe@omnilan.de>
In-Reply-To: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
References:  <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de> <1439301337.11.1606815206810@localhost> <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de> <286917313.21.1606836130991@localhost> <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 01.12.2020 um 16:34 schrieb Ian Lepore::
:
:
:
>> You can define these in /boot/loader.conf:
>> #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
>> bus
>> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
>>
>> Maybe that helps.
>>
>> Ronald.
>>
> Those settings control waiting before mounting root.  Harry's problem
> is that root is mounted quickly, before other drives are ready for zfs.
>   
> The zpool script waits for 'disks'.  It would be nice if the cam
> subsystem had something like a sysctl it set to indicate when initial
> probing for disks was done, then there could be an rc.d/camprobe script
> with 'PROVIDE: disks' which waits for the probing to complete.
>
> -- Ian

Until something described above is available, or anybody is aware of any 
other trick,
here's a tested workaround: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251610

It turned out that also swapon and dumpon suffer from early 
root_hold_wait() release.
For dumpon, cam(4) doesn't even start probing.  Luckily all target:LUNs 
are visible at that earliest stage in rc.d/dumpon.
So that's the point where I check if any real target is in state 
unattached (()) or probing ((aprobe)).
I don't know details of the involved vfs.root_mount_hold sysctl, but 
assume this is dead end currently...

Best regards,
-harry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a43531d6-8828-89aa-4d6d-6bcb9fb75cfe>