[PC-BSD Dev] Wild idea to speed up boot process
imp at bsdimp.com
Mon Aug 19 12:43:30 PDT 2013
Two issues here:
(1) The buffer cache will make reading off media as fast as reading from RAM (since you need to load the RAM, and the delta in compression is likely tiny since configuration data from /etc is tiny). I'm not sure it would help much in the boot time.
(2) NanoBSD has a mechanism to cope with all the issues that you are talking about here. You might want to look at what it does. It doesn't bother with unionfs, preferring instead to load the "known good" configuration from persistent media into RAM and running from there (although there's a minor issue with /etc/master.passwd when users change their passwords).
On Aug 19, 2013, at 12:21 PM, Claudio L. wrote:
> 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 back.
> Dev mailing list
> Dev at lists.pcbsd.org
More information about the Dev