rc.d script to load kernel modules
jhell at DataIX.net
Sun Jun 12 21:21:00 UTC 2011
On Sun, Jun 12, 2011 at 01:52:58PM -0700, Doug Barton wrote:
> 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.
> 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.
Yes this is what I was agreeing to in a sense which is what Gary stated.
> 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).
Yeah his message was around what I was thinking was wrong with loader or
not neccesarily wrong but what it was limited to that was similiar to
one of my previous messages stating contention, limitation, etc...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110612/38e9144a/attachment.pgp
More information about the freebsd-current