From the patent description it doesn't seem that much different from staged remote booting of diskless workstations - something that seems very 1990's.
To recap, a long time ago, when God wore short trousers and I didn't have white hair Edmund Sutcliffe and I implemented a staged remote boot environment at the University of York - Edmund had previously done some prior work on this at Bangor.
The way it worked was this:
Machines had no internal hard disks. When a machine fired up the boot rom on the network card sent out a broadcast message and a bootserver replied and allowed the client machine to download a boot image, which as essentially a dd'd 1.44Mb floppy image containing an operating system, and network drivers, plus some configuration information.
In the original version there was a single boot image. In later versions there were multiple boot images die to the need to support different hardware configurations. We had a backend database that allowed the bootserver to lookup the ether address of the calling device, and provide a boot image based on that ether device.
This proved rather useful as it allowed us to have special purpose ase well as general boot volumes.
One example of a special purpose volume was a dedicated workstation access for email reading alone where we took some old computers with limited memory, network cards and no hard disks. I then developed a specialist 1.44Mb floppy image with an operating system on it, a tcp stack and a locked down version of kermit (actually ms-kermit and freedos) in terminal emulation mode that logged into an old Sun server and forced the user into pine. Logging out of the system forced the pc to reboot (basically we waited till we saw the word logout go past) to ensure a clean session for the user - basically a quick and dirty university email reading terminal - login, read mail exit and walk away. Another example was a variant on the same theme for dedicated library catalogue access.
Unlike these specialist environments what the general models did, after starting the operating system and network was to mount a virtual disk image that other operating system components and continue booting. We also experimented with creating a virtual disk in memory and copying components to that. Memory constraints meant that it didn't give us a significant advantage, so we went back to network volumes on topologically close servers for better performance. It also mounted a second disk image for applications and a third, writable, volume on a per user basis to allow users access to filestore to save their work.
As the user storage volume was sitting on a Unix server, they could potentially access it over the internet. As this was 1992 that meant ftp and terminal access, but nowadays it would mean webDav.
So, the boot sequence for general machines was:
- mount hardware specific startup volume
- mount the rest of the operating system and continue booting
- mount the user and application volumes
In the case of machines with hard disks, the sequence was much the same with the local disk being treated as cache and scratch space. This allowed a portable machine to have files coped to a directory on the local disk from a users network storage, the machine disconnected from the network, and, provided it had a valid local install of the operating system it could boot up locally and still access these files. I'd like to claim we provided some clever synchronisation a la Dropbox, but alas no, we didn't think of it at the time.
Now what we did was arguably clever for its time, as it meant that we had only a small number of boot volumes to maintain, and the separation between specific and component environments meant application deployment was pretty simple, but it was by no means unique.
While we used PC-NFS you could easily have built it using a range of other network solutions. What I am struggling to understand however is how does this differ in concept from Operating System Streaming ?
No comments:
Post a Comment