Since settings in the /boot/loader.conf are fed directly into the boot loader at system startup, I clould speed up the boot process to load most tunables in /etc/rc.conf, if I got it right.
Correct. In fact, it's usually recommended not to overuse
/boot/loader.conf and only add settings or load modules which are required to actually boot the system.
Basically... just because you can use one (or the other) file to load kernel modules doesn't automatically imply that you should.
An additional point concerns ZFS. Since I boot from ZFS I have zfs_load="YES" in /boot/loader.conf and zfs_enable="YES" in /etc/rc.conf to mount pools during initialization. Is one obsolete?
No.
Let's reset the clock 3 years back and let me have a shot at the original question.
So...
/boot/loader.conf is used by the boot loader to apply settings and load kernel modules which are required to boot the system. Booting a system roughly consists of 2 major parts. First the kernel gets loaded and it starts to detect & initialize your hardware. Then it will mount the root filesystem and transfer control to
init. This is a standard procedure on all Unix-like systems, except Linux which replaced
init with the monstrosity that is
systemd thus making it really hard to consider it a serious Unix-like system anymore (but that's my personal opinion on the matter).
Back to the story: init will then take control and start other services and programs in order to fully boot the system (think about the
rc.d structure on FreeBSD). And
rc.d is mostly controlled by... you guessed it:
/etc/rc.conf which controls the whole thing.
I think a good way to get a better impression is to look at
/boot/defaults/loader.conf and
/etc/defaults/rc.conf. You'll notice that the default
loader.conf only deals with very specific boot issues; what kernel to load, if a splash screen should be used, the delay of the boot menu, what logo that boot menu should have and of course also if extra kernel modules are required.
Whereas
rc.conf only deals with userland issues; which services to start and what settings to use (from network related to filesystem related).
Fun fact: mounting your filesystem is a userland problem, indicated by the existence of
/etc/rc.d/FILESYSTEMS (there's more, but I'm trying to keep this short & simple).
Therefor: ZFS in
/boot/loader.conf is required to provide the kernel with ZFS support so that it can access your ZFS pool, whereas ZFS in
/etc/rc.conf is required to make sure the filesystems get mounted.
So how come the boot loader can access ZFS while your kernel wouldn't be able to without the entries in
loader.conf? (that would be my next question anyway). Simple: because of the bootloader version which got installed:
Code:
peter@zefiris:/etc/rc.d $ ls -l /boot/gpt*
-r--r--r-- 1 root wheel 66098 Nov 12 18:16 /boot/gptboot
-r--r--r-- 1 root wheel 114754 Nov 12 18:16 /boot/gptzfsboot
One has support for ZFS whereas the other doesn't (only UFS).
So here's the issue: what do you think would happen if the kernel wouldn't be able to access the root fileystem? For example because it doesn't know about UFS or ZFS?
Then it'll prompt you about not being able to access the root filesystem and ask you to specify it.
And what about ZFS tunables? I put all of them in
/boot/loader.conf but i read somewhere that some ZFS tunables could be used with
sysctl(8) and therefore go into
/etc/rc.conf. Should I keep only those in
loader.conf which can be only adjusted at boot time?
Depends on the tunables. Do you really need to tune ZFS in the first place?
Anyway, I always play that safe and put it into
loader.conf which will then transfer all that to the kernel and that's the end of that. It depends on the tunable but why take the risk..
-- will be looking into this some more...