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.
<br><br>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.
<br><br>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.
<br><br><div class="gmail_quote">On Jan 11, 2008 7:07 PM, Jon Pruente <<a href="mailto:jdpruente@gmail.com">jdpruente@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The difference is that the raw speed from a HDD is faster than flash,<br>esp. since it is being filtered through USB. The seek times on decent<br>flash are pretty dang good compared to HDD. That's where the speed<br>
comes in as it's an order of magnitude faster in some cases. I<br>wouldn't use flash for streaming A/V but it should be fine for an OS.<br></blockquote></div><br>