--- "John W. Linville" <linville@xxxxxxxxxx> wrote: > On Thu, Jan 25, 2007 at 08:13:37AM -0600, Josh Boyer wrote: > > On Thu, 2007-01-25 at 08:48 -0500, John W. Linville wrote: > > > > Anyone have more technical information? I wonder how much the > vendors > > > are allowed to share with us? > > > > I recommend exercising caution and doing your homework when > thinking > > about implementing these things. > > Perhaps my request for more information seemed unclear? Some information I can add, which really is on the throwing caution to the wind side of things (read: unionfs (dm equiv???)), is this feature outline I brought up in the livecd arena long ago (and am only now remotely close to testing), which could easily be adapted from the cd to the flash+hd arena- early boot file seperation- One of the better complaints I've heard about particular livecds is that they 'sound like a bag of nails' while booting. I.e. seek thrashing. One way to get around that, is I believe the accelrated knoppix cloop profiler solution from some folks in japan. An alternate way to get similar benefits might be achieved thusly- - when creating a livecd, do a test boot, tracking all files accessed by the time gdmautologin aquiesses. To be thorough, you would need to post process this and tag with classes, and make sure other files in the same class get included (i.e. some driver autoloads under your test boot in qemu, and you need to make sure that alternate drivers get added to the list). - then, seperate these files into a seperate filesystem image on the livecd. For an extra 3%(?), use mkisofs sort to put these on the outtermost part of the disc. Now, when booting, use a unionfs of these two filesystems, and you will (it seems in my theory) drastically reduce seeking. You may also choose to simply load the entire early-boot-filesystem intoa ramdisk in a single long read. With the latter, you might even be able to pull the old broken raid mirror trick to discard the ramdisk copy freeing up ram post-boot. ( yeah, very similar stuff to readahead. Let me know if I'm not grasping some existing functionality of readahead ) - Now, in the flash memory accelerator scenario, you can easily take this style boot sequence, and store your early boot files in flash. Thus if the user dedicates some attached fast flash to the system, they can utilize the performance benefits(?). Anybody agree/disagree that this approach would be useful? -dmc/jdog ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
