Preloading [WAS: Re: SuSE Project SUPER]

[Douglas McClendon]

David Nielsen wrote:
> søn, 13 01 2008 kl. 21:44 -0900, skrev Jeff Spaleta:
>> On Jan 13, 2008 5:47 PM, Eric Sandeen <sandeen at redhat.com> wrote:
>>> Well, I looked into the readahead util for boot time, and it seemed to
>>> hurt more than help.  But ongoing preload that learns & adjusts to usage
>>> patterns could help I'm sure, if done right
>> That wont help the critical first impression phase.. before
>> application usage patterns are established and people are feeling out
>> the release.  And to be more blunt about it.. it won't help first
>> impression from the reviewers who run a distro just long enough to
>> figure what they like and don't like about it and want to get their
>> review in within the first week of a release.
>> How many people end up relying on the first impression of others to
>> form their own impressions?  Adaptive methods that only help boot
>> speeds after multiple reboots with extended usage pattern trending
>> isn't really going to impact the impression people have one damn bit.
>>
>> And it wont help livecds where state information is lost between reboots.
> 
> Would it be possible to pre-seed such an adaptive scheme.. we know what
> we call on boot on a out of the box F9 final.

Personally of course, I think the long term ideal solution might end up 
looking like my method with the livecd, percolating to normal usage.

I.e. my method does a precooking boot under qemu during livecd compose 
to get file access order.  Then creates the ext3 fsimage on the livecd 
with that sorting order, by just copying the files in order.  Then when 
booting, preloads a chunk from the beginning of the fs into ram(tmpfs), 
in one big long read.  Then after boot is done, discards the chunk in 
ram.  (And the size of the chunk is determined by how much ram the 
system has.)

This already has a benefit of minimizing seeks for disk based 
installation once this ext3 image is copied to the hard drive, during a 
normal livecd installation now.

The key to making this an ideal disk-boot solution, is that you need a 
daemon which watches each boot, and resorts the blocks on the ext3fs 
such that the earlier they are accessed relative to boot, the closer 
they are to the outter rim of the filesystem.  And then using the same 
devicemapper ram caching trick during disk-boot as during livecd-boot.

Note, the above method doesn't minimize seeks like sorting does, it 
removes them, as a huge chunk is read into ram with just a singe seek.

I suspect something similar had been discussed for disk-boot before, but 
probably has been shelved because of the trouble of keeping the fs 
sorted.  I'm amazed no one else however noticed how easy it is to apply 
to the livecd case, where seeks are drastically worse, and it is 
drastically easier to get the filesystem sorted.

-dmc



  Then as usage changes,
> updates are issued and such the adaptive stuff would be able to keep the
> preload system in as close to an optimal state?
> 
> That would seem to be the best of both worlds to me, but then again I'm
> a self-admitted bumbling fool so what do I know.
> 
> - David
> 
> 
>