| PLEX86 | ||
Very slow booting and running and braindead OS's 4540Very slow booting and running and braindead OS's 4541 Well, you could do that in Unix, but it's generally not done - the disk(s) with the system data are generally the same disk(s) as have the boot information. It seems to me... "if the boot medium cannot go away" does not parse. The boot medium CAN go away. The only reason the boot medium may NOT be able is because it is physically colocated with a filesystem that CANNOT. The boot blocks are just wasted space from the point of view of the OS once it is done booting. It comes and goes from fashion. Right now I'm composing on a machine that has eight mounted filesystems, only one of which maps directly to a single physical disk (a CD-ROM). The root filesystem is mirrored across two physical disks. Two other filesystems are the bulk of the storage and are spread across eight and six disks. The remainder are virtual filesystems providing special services. Making a bit-copy of a live filesystem is tricky (because you never know when process-X is going to make a change to a file while process-Y is in the middle of copying the bits). Typically you can avoid a reboot by bringing the system to single-user mode (which in application really means "kill off all but a few blessed processes and disallow logins until I say it's okay again"), copy the filesystem, umount the old one, mount the new one and set the knob back to "okay, you can come in now!" although the difference between "go away, I'm going single user" and "go away, I'm rebooting" really is kinda academic. Because this is an untenable situation for many systems, there are filesystems that are engineered to make live-system snapshots practical, those are guaranteed to leave the filesystem itself in a consistent state, but not necessarily the files. Because even THAT is an untenable situation for some systems, there is a whole family of mirroring techniques, typically done at the block (rather than file) level. Depends on the OS ... Some support remounting root, some don't. Most don't these days -- it's a use case that just *isn't worth supporting*. Very slow booting and running and braindead OS's 4542 AncientHacker Somewhat off-topic, but it might have been a firmware thing: The Burroughs TD850... Another BIG Mainframe Bites the Dust re: the future system project was going to have lots of stuff like that (as well as gobs of other stuff) ... and would have replaced 360 (and early 370). however as... The use case that *IS* well supported is "make the root filesystem independent of any single physical thing". The end result is the same "I can replace the physical disks that root is using without going out of timesharing" ... the mechanism has changed to keep up with fashion. What you keep ignoring is -- there is no way of separating the DATA that is *IN* Smokeydevice from Smokeydevice in the year 2006. For general purpose live filesystems, there does not exist removable media. One *CAN* build their root on a floppy, but it would be such a performance dog that you'd really wish you hadn't.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Computer software consists of only two components: ones and zeros, in roughly equal proportions. All that is required is to sort them into the correct order.
|
||||
Very slow booting and running and braindead OS's 4541 Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||