The SMF repository build at first boot is pretty slow as we all
know. This is even worse when dealing with diskless clients over
NFS where it can easily take 25+ minutes for the 150 or so service
manifests to be imported (and that is for a fast Galaxy).
This is not a nice first time user experience of Solaris 10 and
in my eyes lets the OS somewhat down.
There is an RFE (#6351623) to address this, but it only sits at
priority 4 (=low) so far, so I guess it is unlikely to get
addressed anytime soon.
After the discussion with a colleague yesterday, the idea of
building the repository in ramdisk (tmpfs/swap however you want
to call it) came up. This should be a much much speedier way
than building the repository on a disk file like
/etc/svc/repository* which is prone to slow access and all
the sqlite/locking contention.
The ideal directory to build this would in my eyes be
/etc/svc/volatile
as it already is an in-memory representation. Now if I could
only tell svc.startd and svc.configd to use that instead of the
default /etc/svc. Any ideas how to do that?
I played around by adding this at the top of
/lib/svc/method/manifest-import:
SVCCFG_REPOSITORY=/etc/svc/volatile/fast_repository.db
export SVCCFG_REPOSITORY
and indeed the repository was build in seconds when booting
in /etc/svc/volatile/fast_repository.db. So that looked
promising.
However, I never got the OS to really use that alternative
repository then and after the (fast) manifest- import the
real boot and start of services then failed. Any hints on
how to maybe achieve this would be much appreciated.
In the end I think the solution could be something like this
1) at boot (before the initial manifest-import) copy any
existing repository into ram:
cp /etc/svc/repository* /etc/svc/volatile/
2) Then, when the manifest-import happens, create/update the
repository in RAM only
/etc/svc/volatile/repository*
which will be really fast.
3) Then have svc.startd and svc.configd close their open file
descriptors to the volatile repository, move the repository
from the volatile ram area back into /etc/svc on disk and have
svc.startd and svc.configd re-open the finished repository
from there and continue in their usual fashion.
I am not sure if this can work without svc.startd/svc.configd
modifications. Is it possible for example to set an environment
variable today that defines an alternative repository path
to be used by svc.startd/configd or is /etc/svc hardcoded?
Any opinions, ideas how to achieve this are much appreciated.
-Marcus
