I wrote: > I have worked with Unix systems in the past with separate /usr filesystem > (SCO OpenServer 5 - ahh, nostalgia). Back then we had to create a boot and > root floppy (yes I know some youngsters have probably never seen one) and I > can recall the problems I found making enough room on the root disk to > include cpio (so I could read the backup tapes and restore /usr).
I see that's not that clear - it was two floppies. The first was the Boot floppy which held the kernel - statically linked with the modules (drivers) the system needed as was standard for the system. The second contained the root filesystem. Each was limited to 1.4MByte unless you had esoteric hardware - like the 2.8MByte floppy I think IBM did. If your kernel was more than 1.4M then you were out of luck. If you tried to put more than 1.4M on the root fs then you were out of luck - the default selection of files didn't leave enough room to add cpio. Without these two floppies, the system was to all intents unrepairable should it have a problem ! No such thing as a "live system" cd back then ! I suspect people looking at "desktop" environments have never been down the route of carefully designing systems for best performance (for the hardware that's within your budget) - small fast disks (raid 10) for active data, larger slower disks (raid 5) for "less active" data, carefully balancing the disks across multiple SCSI busses to maximise throughput, etc. Those were the days - raid controllers that didn't support array expansion, off-line disk rebuilds, 2 days to download a driver disk update (no ADSL back then). Oh yes, no dynamically sized disk caches in SCO OpenServer ! That was a hard configured setting, with a hard coded maximum size limit - and yes I found out the hard way that the stated size really was the maximum (go one block larger and it just didn't boot) - see boot and root floppies above :-( While it's not really an excuse, I can see how someone who's never had to consider resource constraints might ignore "good practice" regarding resource usage. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
