Disk files

A disk file had the same structure as an ECS system file. A portion of the file could reside on the disk and a portion in ECS. Which portion was in ECS varied with time. If a read or write request was made to a portion of the file residing in ECS, the action would proceed as fast as if it were a read or write on an ECS file. On the other hand, if the request was made to a portion not in ECS the request would proceed more slowly. An action was available to attach one or more blocks of a file. This action resulted in those blocks being moved into ECS, but computation could proceed while the move was being made. If subsequently the program attempted to read or write data in the attached blocks, the program would be forced to wait until the blocks were in ECS, and then would be permitted to continue. Thus the system essentially provided a buffering facility. Figure 4 gives an example. Another action that could be performed on disk files was to place parts of them in subprocess maps. This had an effect similar to placing ECS files in a map, portions of the disk file became accessable through load and store instructions. One step in achieving this result was to implicitly attach the blocks containing the mapped data, thus moving them into ECS.

 

Figure 4: Example of an ECS file representing a portion of a disk file (128 word data blocks, 8 pointers in each second level pointer block).

10#10

It was assumed that the total space desired in ECS by all processes would exceed the capacity of ECS, so we intended to provide two states for a process, swapped in and swapped out. When swapped out, those portions of disk files being held in ECS for the process would be moved out to the disk and the activity of the process would be suspended. We further assumed that space required in ECS for a process beyond that held in disk files would be very small, so that many processes could exist in a swapped out state.