[PC-BSD Dev] Wild idea to speed up boot process
claudio at hpgcc3.org
Mon Aug 19 11:21:46 PDT 2013
On 08/19/2013 06:09, Luca Ferrari wrote:
> 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.
Indeed, 3 is the key problem. Since unionfs doesn't work, and even if it
did, doesn't quite behave the way we'd need it, we'll need a custom
unionfs. What better opportunity to log every file opened than at this
filesystem union driver? When a file is opened, two things can happen:
a) It's already on the RAM disk, so we serve that file (but only if it
isn't listed as invalidated).
b) It's not on the RAM disk, in which case we get it from the other file
system, and save a copy on the RAM disk.
The real problem is how to do a few tests **before** doing all that work...
> 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.
This is a good idea, we'd need to mount root with atime=on and see what
files are being used.
> The 4 requires a few attention to avoid ramdisk corruption (e.g., the
> user shuts down the computer while the rebuild is in progress).
I'm not thinking of a "rebuild" process, but more like this:
1) Missing files are being added to the RAM disk on-the-fly during boot.
2) When the user logs in (or even before), a script is started that runs
a command that signals "end-of-boot" to the ram disk, causing it to
simply dump all its contents to disk. Then a deamon is started that
monitors the files in the ramdisk for writes, and lists them as
invalidated when a write occurs.
This way the ram disk is not active all the time (and therefore can't
get corrupted), and also every write to a file in the ram disk would
immediately invalidate the file, causing it to reload from the base
filesystem on next boot. Also, since the ram disk is written in whole
after boot, losing power doesn't affect anything. The only corruption
would be if someone stops the deamon, in which case files that were
changed afterwards would not be invalidated on the ram disk and used
instead of the new files (they were supposed to be good files on the
previous boot, so it's not as bad... I think).
> However I guess you should previously measure what is the speedup of
> having almost everything (/etc) in a ramdisk.
The first step is to get a list of accessed files, and their size. If
it's too much for a ram disk then I'll forget the whole idea.
Thanks for your idea of the access time. I'll give it a shot and report
More information about the Dev