Re: considering root mounting /dev/ramdisk

["Peter L. Peres" <plp@actcom.co.il>]

I'm not a big authority on this, but I've managed to put together one
single-floppy linux system that runs in the way you describe more or less,
without relation to etherboot, so here are my 2 bits:

- The kernel limits the size of the ramdisks. It needs to be hacked to
support at least one extra large ramdisk efficiently, with minimal
effort, imho.

- The transfer of such violent amounts of data over 10 MB ethernet is
prohibitive. 170 MBytes over this is at least 170 seconds (3 minutes), and
that assuming that there is only one client and the network is not active.
Most people who can afford a netboot server can also afford $200 for an
EIDE hard disk instead of a 3-minute boot after turn-on. With 100 MB ether
it is still in the 20 second range, assuming one client only. Try to
imagine what happens to a whole office booting this way.

- A more realistical scenario assumes that about 20 MB are transferred in
the beginning, the system goes to a graphical runlevel, and transfer of
often used applications continues in the background. A dedicated mirroring
daemon should take care of this, and look at the frequency of usage of
programs to know what to load first, or use recipes of programs required
to reach a goal (a la GNU make). Then, it could switch the runlevel after
the relevant resources have been loaded completely etc. This sounds easy
and a good sh script can do it but more than that is required and it is
not so trivial. 

- Running such a system without a super-reliable UPS is unthinkable. The
cost of the UPS required for each station is such that a cheap hard disk
is cheaper (a dedicated mains circuit is even more expensive and less
reliable). Any data in the system that is not backed up will go up in
smoke the moment a power glitch arrives. Now, think of a large building
full of computers set up like this, and down in the street a bulldozer
cuts the electricity cables near a construction site... 

- Any setup changes made by the user will not be conserved across sessions
unless there is a way to send them back to the server. This can be very
annoying, and storing user profiles is complex, unless all the users have
an account on the server each, or a database is used (very complex).
Setting up all this for a single machine is not worth your while. The
required effort asks for a marketable solution to balance the invested
time and effort. 

- Doing a post-mortem debug session on such a beast is impossible, unless
a way is found to export the logs in real time, for example using a
printer while debugging, or by adding a back signalling protocol to log at
the server (no, it can't be sys/klogd, it isn't running during kernel
boot). Doing post mortems on a production system, where it matters, is
even more complicated. On a diskless system, when things run away, they
run so fast you can't see or understand anything. I know this from
embedded controller experience and with that single floppy linux thing I
made.

hope this helps,
	Peter