3 ms·

Realistically, if a disk server goes down, there are two possible reasons: 1. The disk hardware is bad. By all means, take everything down until you replace th

by msla 8y ago

Realistically, if a disk server goes down, there are two possible reasons: 1. The disk hardware is bad. By all means, take everything down until you replace the disk so you don't get garbage in important files! 2. The disk driver software is bad. By all means, take everything down until you replace the software so you don't get garbage in important files! In neither case is simply bouncing the disk server an acceptable answer. Debugging and fixing the underlying problem is essential, and that requires taking the whole system down.

Fnoord 8y ago
The question is rather: would a unikernel or monolithic kernel have behaved differently? Probably #1 (or a nefarious person being root), but you do have backups and redundant servers, right? I'd read SMART logs first. Back when my Death Star died some 20 years ago I remember it getting more difficult by the day to spin it up. But once it worked, it'd work fine.. until the machine tried to read from a bad sector (a good OS wouldn't have frozen on that but this was Windows 9x). Here are some alternative possibilities: 3. Physical compromise; e.g. a cable got yanked. 4. Disable write caching and continue despite the driver or hardware being bad. 5. There is no quick way to get physical access. 6. A disk server isn't necessary to keep the system up. Goes well with #4. If you look at how it all went, the massive redundancy of cheap commodity hardware won. Containers add further on that, and no doubt more bloat can be removed via a unikernel or microkernel (leading to smaller attack service but also more complexity). But that doesn't mean every aspect of such a machine needs to keep running, and it does imply a FOSS solution.
toast0 8y ago
The disk server could conceivably fail because a disk took an absurdly long time to respond to a command --- by all means, update the firmware, but in the mean time, restarting the disk server (and replaying any pending writes, somehow) will get you back on track. At least restarting the disk server in read only mode allows reads to continue to function -- maybe even allows for an orderly evacuation of the data.
- Fnoord 8y ago
  Good thinking. Read-only mode is an interesting suggestion. Filesystems allow this as well, and it can allow for the live extraction of data having to resort to professional recovery means (ie. physical and expensive). I've had times with bad sectors (Deathstar at the very least) where reads would result in complete OS lock up or very laggy situation. That can be solved by only trying so many times to read (though that was on Windows 9x with PATA).

by msla 8y ago

Fnoord 8y ago

The question is rather: would a unikernel or monolithic kernel have behaved differently? Probably #1 (or a nefarious person being root), but you do have backups and redundant servers, right? I'd read SMART logs first. Back when my Death Star died some 20 years ago I remember it getting more difficult by the day to spin it up. But once it worked, it'd work fine.. until the machine tried to read from a bad sector (a good OS wouldn't have frozen on that but this was Windows 9x). Here are some alternative possibilities: 3. Physical compromise; e.g. a cable got yanked. 4. Disable write caching and continue despite the driver or hardware being bad. 5. There is no quick way to get physical access. 6. A disk server isn't necessary to keep the system up. Goes well with #4. If you look at how it all went, the massive redundancy of cheap commodity hardware won. Containers add further on that, and no doubt more bloat can be removed via a unikernel or microkernel (leading to smaller attack service but also more complexity). But that doesn't mean every aspect of such a machine needs to keep running, and it does imply a FOSS solution.

toast0 8y ago

The disk server could conceivably fail because a disk took an absurdly long time to respond to a command --- by all means, update the firmware, but in the mean time, restarting the disk server (and replaying any pending writes, somehow) will get you back on track. At least restarting the disk server in read only mode allows reads to continue to function -- maybe even allows for an orderly evacuation of the data.

Fnoord 8y ago
Good thinking. Read-only mode is an interesting suggestion. Filesystems allow this as well, and it can allow for the live extraction of data having to resort to professional recovery means (ie. physical and expensive). I've had times with bad sectors (Deathstar at the very least) where reads would result in complete OS lock up or very laggy situation. That can be solved by only trying so many times to read (though that was on Windows 9x with PATA).