Orthogonal Persistence OSes like Grasshopper and EROS unify the file system and virtual memory. They save part or entire state of the kernel and applications environment at certain points in time to the hard disk storage. They advantages of orthogonal persistence are that it eliminates code for file systems and simplify the programming process since the concept of files is eliminated. All application environment data (heap, stack, etc) and perhaps the kernel itself is simply saved to the hard disk.
But what are the problems and disadvantages of orthogonal persistence? Does anybody have any idea?
Problems/Disadvantages with Orthogonal Persistence.
-
carbonBased
RE:Problems/Disadvantages with Orthogonal Persistence.
I know very little about this topic, unfortunately (except that it's an incredibly interesting, and growing osDev philosophy)... but it was my understand that an orthogonally persistant OS will still require file system support (?)
If one were to make memory and HD completely indistinguishable, how would a user install a new program? Or is the theory simply that the computer has (for example) 45GB of memory (mem + hd!), and all programs that are available on the system are "loaded in memory"?
Quite an intriguing situation... and VERY powerful, I would think... intuitive to the user (the end user never could tell the difference between the "hard drive" and "memory"... "Sir, honestly, you don't have 60GB of memory...")
A suppose a couple possible problems could be...
memory fragmentation: once the OS is deloyed, you're running the exact same memory manager through the _entire_ life of the OS (the memory manager never really "reboots" in such a system)...
HD crash: what happens in this case? How do you run an integrity check on an HD that isn't really an HD? Is there a format to the HD, or is simply an array of 4kb pages, like memory?
computer crash: memory/HD is left in a messed up state... reboot... memory is still in a messed up state (its persistent, afterall)... reboot, etc, etc... you're stuck in a loop. I had this with 'doze once, it kept loading a program up at startup which faulted the system.
Offhand, I can't think of anything (and my minds a little fuzzy, so I don't even know how valid the above are). It seems to me, it'd be a difficult thing to perfect, but once done, would be quite the system to contend with.
Check out some of the OSs out there that follow this philosphy, and see what they have to say about it (isn't Tunes designed to be orogonally persistant?)... they'll probably be a better help than me
Jeff
If one were to make memory and HD completely indistinguishable, how would a user install a new program? Or is the theory simply that the computer has (for example) 45GB of memory (mem + hd!), and all programs that are available on the system are "loaded in memory"?
Quite an intriguing situation... and VERY powerful, I would think... intuitive to the user (the end user never could tell the difference between the "hard drive" and "memory"... "Sir, honestly, you don't have 60GB of memory...")
A suppose a couple possible problems could be...
memory fragmentation: once the OS is deloyed, you're running the exact same memory manager through the _entire_ life of the OS (the memory manager never really "reboots" in such a system)...
HD crash: what happens in this case? How do you run an integrity check on an HD that isn't really an HD? Is there a format to the HD, or is simply an array of 4kb pages, like memory?
computer crash: memory/HD is left in a messed up state... reboot... memory is still in a messed up state (its persistent, afterall)... reboot, etc, etc... you're stuck in a loop. I had this with 'doze once, it kept loading a program up at startup which faulted the system.
Offhand, I can't think of anything (and my minds a little fuzzy, so I don't even know how valid the above are). It seems to me, it'd be a difficult thing to perfect, but once done, would be quite the system to contend with.
Check out some of the OSs out there that follow this philosphy, and see what they have to say about it (isn't Tunes designed to be orogonally persistant?)... they'll probably be a better help than me
Jeff
-
nicholas
RE:Problems/Disadvantages with Orthogonal Persistence.
I am wondering if applications in such an OS is restricted to a "data space" of no more than 4GB on a 32-bit machine.
-
Khumba
RE:Problems/Disadvantages with Orthogonal Persistence.
You'd want to make sure the OS is pmode!!!
-
smurphy
RE:Problems/Disadvantages with Orthogonal Persistence.
idea:
what about 64 bit systems? they will be able to hold endless (18446744073709551616 bytes) off virtual data. such a system could be used to store _all_ the files in any computer in the virtual memory
just remap the currently executing blob to the beginning of the memory. all the blobs could have handles pointing to them. if the blob that is executing has the rights to modify any of the other blobs in the system, the pagefault that occurs when it reads/writes to the virtual memory location that corresponds to some blob will load whats in the file. if the blob dosnt have the rights to modify the other blob, it will simply not load whats in the file, but instead return some error value.. or whatever.
there might be serious fragmentation is this kind of blob-system.. hmm. the files could be placed VERY (virtualy) far from each other, to avoid them to crasch into each other.. or?
what about 64 bit systems? they will be able to hold endless (18446744073709551616 bytes) off virtual data. such a system could be used to store _all_ the files in any computer in the virtual memory
just remap the currently executing blob to the beginning of the memory. all the blobs could have handles pointing to them. if the blob that is executing has the rights to modify any of the other blobs in the system, the pagefault that occurs when it reads/writes to the virtual memory location that corresponds to some blob will load whats in the file. if the blob dosnt have the rights to modify the other blob, it will simply not load whats in the file, but instead return some error value.. or whatever.
there might be serious fragmentation is this kind of blob-system.. hmm. the files could be placed VERY (virtualy) far from each other, to avoid them to crasch into each other.. or?
-
carbonBased
RE:Problems/Disadvantages with Orthogonal Persistence.
It'd have to be, yeah.
BUT, that's only a limit per process. There could be an infinite number of processes running, each with a different 4GB mapping (spanning GB's of memory, or disk).
In essence, on a 32-bit processor, even with maxed out memory, you're only going to have a total of 4.2GB loaded at one time, but you're still able to remap any of those to a disk, resulting in well over 4.2GB total.
The biggest problem I can see in this kind of system is that your memory management and paging code has to be _ROCK SOLID_! It must deal with segmentation in an incredibly efficient manner, and must be able to page to and from disk quickly.
If not, after running the OS for a few weeks, you're "memory space" will keep expanding, and straining the system more and more (trashing, etc). Memory leaks will remain permanent... a simple reboot wont fix them.
Jeff
BUT, that's only a limit per process. There could be an infinite number of processes running, each with a different 4GB mapping (spanning GB's of memory, or disk).
In essence, on a 32-bit processor, even with maxed out memory, you're only going to have a total of 4.2GB loaded at one time, but you're still able to remap any of those to a disk, resulting in well over 4.2GB total.
The biggest problem I can see in this kind of system is that your memory management and paging code has to be _ROCK SOLID_! It must deal with segmentation in an incredibly efficient manner, and must be able to page to and from disk quickly.
If not, after running the OS for a few weeks, you're "memory space" will keep expanding, and straining the system more and more (trashing, etc). Memory leaks will remain permanent... a simple reboot wont fix them.
Jeff