I guess I can achieve this by making the system boot with one (CF) drive only and then following the upgrade process to add a second drive.
Sure, if that's how you want it to work. With this straightforward scheme, the hard drive will always spin up at boot time, whether you set the "no-spin" jumper or not. And the empeg will pause during boot, waiting for the spin-up per-normal. So the CF card won't gain you much with this setup.
As near as I can see it, the only two worthwhile CF methods are (1) all CF (best overall, but lowest capacity), and (2) CF slave drive as cache, using my hacked kernel (not yet available to others).
You see, the player software wants to READ from all FID directories at boot. So all FID filesystems have to be available and mounted at player startup time, and it has to read the filesystem "meta data" (the invisible glue for tracking directories, free space, etc..) at startup.
Using the stock software, this means all drives will spin up and be read at boot.
The approach I've taken instead, is to not put any filesystem on the CF card (not that this matters), and to use the free space (all of the CF card) as a sector-by-sector low-level disk cache for the real hard disk. The first time it boots, the hard drive spins up and is read as normal, but all read data gets copied over to the CF card at the same time.
The next time it boots, all of the sectors it needs are probably now also present on the CF card, so the hard drive doesn't spin up. The player software still mounts the hard disk filesystems, and scans its directories, BUT.. because all of that data is now present on the CF card, my hacked kernel gets it from the CF instead of the disk. The player software doesn't know about that, and thinks it all came from disk.
Previous Topic
Index
