45 ms·

But the disk does not get corrupt frequently because (1) user apps cannot write to it directly, they have to use a restrictive API, (2) each write operation is

by theamk 5y ago

But the disk does not get corrupt frequently because (1) user apps cannot write to it directly, they have to use a restrictive API, (2) each write operation is limited to a single logical part, and cannot affect other parts and (3) disk structure is designed to be recoverable. As a result, in the existing system, if the video driver gets corrupt and messes up kernel memory, there is a very high probability that all the files are intact and system will be fully usable once I reboot. Maybe the single file that I was working on will be damaged. Compare this to fully persistent memory system, which has a high chance of being unusable afterward.

Someone 5y ago
I expect OSes to be compartimentalized similarly. There’s no way to manage a system with 2^trillions of states otherwise. For example, memory protection mechanisms can be used to protect boot code from tampering, a level above that the core OS used for ‘just above reinstall’ recovery can use a different protection regime, the OS proper allows user modifications after sudo, but otherwise is protected from user processes, etc. Actually, even without disk space being memory mapped I think the MMU (and robust disk drivers) are what gives you that high probability of the file system staying intact when a process goes rogue. It used to be fairly common to lose a disk because some runaway process trashed the in-memory cache of essential on-disk data structures, and the OS than (blissfully unaware of the damage) flushed the incorrect data to disk.
- theamk 5y ago
  Having the per-app compartments, recovery partition, or sudo-only memory is not going to help you if your text editor crashes, and loses all your documents. Or if photo app crashes and loses all the photos you ever had. What you really want is some sort of generic "document" abstraction. So that user app can specify intent (read or write or update) and a document name, and system will enforce it. This way if your photo app gets damaged, the "blast radius" is limited only to the "documents" which are being edited now, which will hopefully be very close to zero. Hm.. I wonder what this sounds like? :) (also: I used MS-DOS (with no memory protection, but with SMARTDRV disk cache) a lot, and crashed it a lot, often by my own code. The disk corruption was not that frequent at all. And in the worst case, you could often recover most of the data with NDD. The viruses and disk failures were far more common causes of data loss)

by theamk 5y ago

Someone 5y ago

I expect OSes to be compartimentalized similarly. There’s no way to manage a system with 2^trillions of states otherwise. For example, memory protection mechanisms can be used to protect boot code from tampering, a level above that the core OS used for ‘just above reinstall’ recovery can use a different protection regime, the OS proper allows user modifications after sudo, but otherwise is protected from user processes, etc. Actually, even without disk space being memory mapped I think the MMU (and robust disk drivers) are what gives you that high probability of the file system staying intact when a process goes rogue. It used to be fairly common to lose a disk because some runaway process trashed the in-memory cache of essential on-disk data structures, and the OS than (blissfully unaware of the damage) flushed the incorrect data to disk.

theamk 5y ago
Having the per-app compartments, recovery partition, or sudo-only memory is not going to help you if your text editor crashes, and loses all your documents. Or if photo app crashes and loses all the photos you ever had. What you really want is some sort of generic "document" abstraction. So that user app can specify intent (read or write or update) and a document name, and system will enforce it. This way if your photo app gets damaged, the "blast radius" is limited only to the "documents" which are being edited now, which will hopefully be very close to zero. Hm.. I wonder what this sounds like? :) (also: I used MS-DOS (with no memory protection, but with SMARTDRV disk cache) a lot, and crashed it a lot, often by my own code. The disk corruption was not that frequent at all. And in the worst case, you could often recover most of the data with NDD. The viruses and disk failures were far more common causes of data loss)