[PC-BSD Dev] Wild idea to speed up boot process

Luca Ferrari fluca1978 at infinito.it
Mon Aug 19 03:09:21 PDT 2013

On Sat, Aug 10, 2013 at 6:12 PM, Claudio L. <claudio at hpgcc3.org> wrote:
> On 08/10/2013 05:21, Luca Ferrari wrote:
>> Uhm...sounds to me like a duplicate of the vnode cache layer: each time
>> access to a file is detected you have to map it to the ramdisk, and then the
>> system maps it into the vnode cache.
> Not exactly, because the cache is empty on boot, and you have to populate it
> as you access the files, triggering a lot of random reads, on files that
> will likely be used only once during boot.
> Traditional caches are not very efficient during boot, unless they are
> persistent, like the L2ARC.

I was thinking about the pushing missing files on the fly to the
ramdisk: this is what the vnode cache does under the hood (for other
The "sequential read" reminds me the trick of having boot stuff in a
specific partition to avoid the heads moving back and forward the
whole disk.
By the way, we have to consider that, even if faster, a sequential
read/write will cause I/O on startup and halt, therefore it sounds to
me a compromise between the speed at which we can load the ramdisk and
use it compared to normal boot process.
So if I get it right the whole thing should be:
1 make a ramdisk with an initial state, let's say /etc
2 mount the ramdisk as soon as the / is mounted, for now use unionfs
(this should be controlled from /etc/fstab)
3 record which files are not in the ramdisk and are used to get to the
final boot stage (i.e., the end of rc)
4 rebuild the ramdisk on background

The 3 is the problem, in my opinion. The first solution that comes
into my mind is a module that performs a syscall hook to handle opens
in order to record somewhere which files are being opened. For a try
and run a shell script that checks the last access time (assuming it
is supported on the /) will suffice to build a list of "wanted" files.
The 4 requires a few attention to avoid ramdisk corruption (e.g., the
user shuts down the computer while the rebuild is in progress).

However I guess you should previously measure what is the speedup of
having almost everything (/etc) in a ramdisk.


More information about the Dev mailing list