[geeks] Dell T105 server arrives

[Lionel Peterson]

>From: der Mouse <mouse at Rodents.Montreal.QC.CA>
>Date: 2008/04/02 Wed PM 12:05:42 CDT
>To: The Geeks List <geeks at sunhelp.org>
>Subject: Re: [geeks] Dell T105 server arrives

>> Sure, but even netbsd would probably install faster if they dd'd a
>> 150 meg base system to the desired partition, then expanded the FFS
>> to fill the partition.  That is, that would be fast if FFS could do
>> that, which I don't think it can.
>
>ffs can.  Many implementations don't support it, but it's not hard.
>Some implementations (eg, Auspex) even support doing it live.  If you
>care about filesystem geometry matching disk geometry (which you
>probably shouldn't, in these days of ZBR and disk-implemented sparing),
>you'll have problems, though.
>
>Of course, that's orthogonal to the question of whether it would be a
>good thing to do that.  Personally, I'm with the people who don't want
>it, for much the reasons already mentioned.

Thinking about it over lunch, I got to thinking, what if the installer was multi-threaded (I'm thinking exactly two threads, but more might make sense), and there was one thread that read the entire distribution into RAM (the 150 Meg NetBSD, for example) *assuming* there was enough RAM, and then another thread (or multiple threads) read from memory and built up the OS image on the HD?

The idea is that the media would be read serially, todays *huge* RAM could be exploited, and writes to the file system wouldn't be interrupted by reads from the distribution media.

A Solaris implementation could look like this:

OK> boot cdrom -Memory

or:

OK> boot net install -Memory

I think that could be interesting (and quick?)

Lionel