rc.d script to load kernel modules

[Doug Barton]

On 6/12/2011 1:43 PM, Jason Hellenthal wrote:
>
> Doug,
>
> On Sun, Jun 12, 2011 at 12:46:58PM -0700, Doug Barton wrote:
>> On 6/12/2011 12:42 PM, Jason Hellenthal wrote:
>>
>>> Yes I agree. I was just stating that simply for the previous post
>>> implying where ZFS was slower than UFS.
>>
>> No, it wasn't. You completely fail to understand the problem. Stop
>> writing, and start reading. As in, read the threads on both -arch and
>> the svn list, and this entire thread again, then wait an hour or two
>> before posting anything else. (Yes, I'm serious)
>>
>
> Yes, it, was. This was not to your post. This was to another fellows
> which don't recall his name ATM but would please be as kind as to
> discard the unuseful comments. I was agree'ing with Gary that its not a
> problem with ZFS/UFS or any mix or match of the two. Perhaps a pause in
> both of our replies would be duly needed.

Gustau's post said in part:

>   For example, in my case, I'm booting from a zfs-only installation.
> Kldloading a ten or twelve modules in loader.conf takes a long time
> compared to a UFS-only installation. Moving them to a rc.d script would
> allow me to save a lot of time during the boot process.

http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025132.html

zfs vs. ufs is entirely irrelevant to the matter at hand, which is 
entirely related to the fact that loading modules from the boot loader 
is always going to be many many times slower than loading them from the 
disk after the system is booted. Kevin was kind enough to elaborate, 
hopefully his explanation is better than mine, and will help you 
understand the problem better.

Meanwhile, to address Gustau's original point, the modules related to 
getting zfs up and running would still have to be loaded in loader.conf. 
My solution is only effective for those modules which are not related to 
getting the local disks on line (which fortunately is the vast majority 
of them).


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/