This article is about single-level storage in a computing system. For single-level memory cells in non-volatile memory, see Single-level cell.
Single-level storage (SLS) or single-level memory is a computer storage term which has had two meanings. The two meanings are related in that in both, pages of memory may be in primary storage (RAM) or in secondary storage (disk), and that the physical location of a page is unimportant to a process.
In modern usage, the term usually refers to the organization of a computing system in which there are no files, only persistent objects (sometimes called segments), which are mapped into processes' address spaces (which consist entirely of a collection of mapped objects). The entire storage of the computer is thought of as a single two-dimensional plane of addresses (segment, and address within segment).
The persistent object concept was first introduced by Multics in the mid-1960s, in a project shared by MIT, General Electric and Bell Labs.[2] It also was implemented as virtual memory, with the actual physical implementation including a number of levels of storage types. (Multics, for instance, had three levels originally: main memory, a high-speed drum, and disks.)
IBM holds patents to single-level storage as implemented in the IBM i operating system on IBM Power Systems and its predecessors as far back as the System/38 that was released in 1978.[3][4]
Design
In early systems, there was a clear distinction between main memory and any secondary storage. In order to process data, programs would use explicit code to read data from secondary storage into main memory, manipulate it in main memory, and then use more code to write it back out to secondary storage again. This distinction remains to this day in most operating systems (OS).
In the 1960s, timesharing and multiprogramming were introduced. In these systems, more than one program might be running at the same time, and each desires to have its own memory to work with. This led to sometimes complex systems where programs would describe the minimum and desired amounts of memory they needed to operate, and the OS would break up main memory into blocks typically known as segments. As there were now potentially many programs running at the same time, each individual program might have less memory to work with than it desired.
Attempts to address this problem led to the development of virtual memory (VM). VM systems break the main memory down into a series of fixed-sized segments, or "pages", and allocate them to programs on demand. Programs are unaware that the VM system exists, they simply ask for memory and will be granted it or denied, as before. The difference is that each program would not be limited to some fraction of the main memory being set aside for it, but would instead be granted access to the entire memory, a fixed "virtual" main memory that was typically much larger than actual physical memory. As programs used up the physical memory, and it eventually ran out, the VM system would examine the pages for data that was not currently needed, and write it out to secondary storage. This was known as "paging". When a program attempted to access values in memory that had been paged, the VM system would once again intervene, writing out some other page of memory and loading the requested one back in. This is invisible to the program, to it, it appears there is a single large memory and its data is always available. Programs written in a VM system are otherwise similar to those on earlier machines. To store data permanently, the program still had to have code to read and write data to and from secondary storage, most typically a file system but also sometimes a database engine.
A single-level store changes this model by extending VM from handling just a paging file to a new concept where the "main memory" is the entire secondary storage system. In this model there is no need for a file system separate from the memory, programs simply allocate memory as normal and that memory is invisibly written out to storage and retrieved as required. The program no longer needs code to move data to and from secondary storage. The program can, for instance, produce a series of business cards in memory, which will invisibly be written out. When the program is loaded again in the future, that data will immediately re-appear in its memory. And as programs are also part of this same unified memory, restarting a machine or logging in a user makes all of those programs and their data reappear.
The operating system takes on the responsibility of locating pages and making them available for processing. If a page is in primary storage, it is immediately available. If a page is on disk, a page fault occurs and the operating system brings the page into primary storage. No explicit I/O to secondary storage is done by processes: instead, reads from secondary storage are done as the result of page faults; writes to secondary storage are done when pages that have been modified since being read from secondary storage into primary storage are written back to their location in secondary storage.
System/38 and IBM i design
IBM's design of the single-level storage was originally conceived and pioneered by Frank Soltis and Glenn Henry in the late 1970s as a way to build a transitional implementation to computers with 100% solid state memory. The thinking at the time was that disk drives would become obsolete, and would be replaced entirely with some form of solid state memory. System/38 was designed to be independent of the form of hardware memory used for secondary storage. This has not come to be, however, because while solid state memory has become exponentially cheaper, disk drives have also become similarly cheaper; thus, the price ratio in favour of disk drives continues: very much higher capacities than solid state memory, very much slower to access, and much less expensive.
In System/38 and IBM i, all data in storage is assigned an address, accessible by processor instructions, in virtual memory, and is referred to by that address, regardless of whether it is currently in physical memory or not. If the data referred to by that address is not in physical memory, a page fault occurs. The page fault is handled by low-level software that reads the page into an available page frame in primary storage.[5][6]
With the IBM i implementation of single-level storage, page faults are divided into two categories. These are database faults and non-database faults. Database faults occur when a page associated with a relational database object like a table, view or index is not currently in primary storage. Non-database faults occur when any other type of object is not currently in primary storage.
