CF to boot Linux

Monty J. Harder mjharder at gmail.com
Sat Jan 12 09:57:45 CST 2008


One of the really attractive features of flash is that it doesn't have to
spin up like a HD.  As motherboard flashable BIOS chips get larger
capacities, the potential is there for a LinuxBIOS to have grub in the BIOS,
several kernels and some filesystems that can be mounted ro on (a) flash
drive(s), so that the system can be booted before the HD even gets up to
full speed.

That's where a break from classic init "runlevels" to the event-based system
of Upstart really starts to make sense.  Since there's really no seek
penalty in flash like there is on a HD, Upstart can spawn a process to deal
with the HD.  Once it's functional, that process can generate an event that
handles optionally fsck-ing the filesystems on the drive and mounting them.
It is a complete inversion from the normal idea that the "permanent" HD is
the boot drive, and inserting a flash drive into USB generates the event.

With a halfway decent amount of RAM, you'd have logging to ramdrive until
the normal HD log filesystem goes online, at which point that event would
trigger dumping of the ram log to the HD.  In the case of portable devices,
it may wait and collect enough to be worth spinning the drive up.  A NVRAM
storage subsystem to act as disk buffer would be really nice for such
applications.

On Jan 11, 2008 7:07 PM, Jon Pruente <jdpruente at gmail.com> wrote:

> The difference is that the raw speed from a HDD is faster than flash,
> esp. since it is being filtered through USB.  The seek times on decent
> flash are pretty dang good compared to HDD.  That's where the speed
> comes in as it's an order of magnitude faster in some cases.  I
> wouldn't use flash for streaming A/V but it should be fine for an OS.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kclug.org/pipermail/kclug/attachments/20080112/9901893d/attachment.htm 


More information about the Kclug mailing list