From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.os2.advocacy
Subject: Re: Brian, your bias is showing ( was Re: OS/2 vs NT features
Date: 7 Sep 92 22:42:32 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <65424@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes:
>> Come to think of it - how can the file system code be pageable? I need
>> the file system to page in needed blocks! For that matter - is the cache
> 
> Why would you need the file system to page?  On most layered I/O architectures,
> the file system doesn't directly control the device(s) that contain the files.
> It talks to a device driver for that.  The paging software can talk to that
> device driver.
> 
> You would only need the file system to page if the pages were kept in a file.
> If the paging area is on a separate partition or area of the disk, then there
> would be no need for the file system.
> 
> Even if the paging area is a file, I would expect the OS to find out where
> it is on the disk, and then talk to it directly, bypassing the file
> system (i.e., the file system is only involved to create the paging
> file).  I think that this leads to simpler file system design, and also
> allows for more powerful and efficient file systems, and makes deadlock
> avoidance easier.

It's no big problem to keep the paging area in a file, and for the OS
to have a simple algorithm for accessing the paging file (an array of
disk "windows" consisting of a base sector and a length to enable the
mapping of the entire file).  I believe the VAX/VMS file system has been
pageable for lo, these many years by using just such a mechanism;  and
page and swap areas on VMS have always been _files_, not _volumes_.
(You can of course make a page file that takes up a whole volume, but
you don't _have_ to;  the data structures are based on a _file_ concept
rather than a _volume_ concept).

It's even possible for the file system to be _overlaid_ by the use of
a similar mechanism -- for example, the PDP-11 RSX file system (F11ACP)
could be overlaid if you were short of main memory space.  The OS dealt
with it by having a base pointer and a length for the disk image.
Naturally this wasn't terribly efficient if you were doing operations
that turned the overlay file (the overlay was set up so that the most
"common" operations didn't have to read in a new overlay, but even so
you could easily thrash the disk...).  

Mapping file space is really about the simplest function of a file
system -- creating and deleting files, extending existing files, managing
directories, and so forth, requires much more code, especially if the
file system is at all complex or "intelligent".

Tim is quite correct, there is no mystery about how this might be done,
and in fact it has been part of the "state of the art" for at least 20
years.  The only question is whether you'd _want_ to be able to do this
in view of the possible performance penalties (most modern systems have
much more memory than those old PDP-11's I mentioned above).  But if the
file system's pages were marked as very "valuable", then they would only
be paged out if you were running very short on memory and might otherwise
run into a memory deadlock situation.

Bruce C. Wright
Newsgroups: comp.os.os2.advocacy