when I first started working in the CS dept back at CMU 9 years ago,
the version of mach in use on department machines at that point
had exactly the feature you describe, using free inodes to store
paging space.  the next version switched to representing the paging
space in a filesystem as a single file, but unlike the current netbsd
"swap files", the file could be grown on demand by the vm system.
later, mach 3 went to preallocated, non-growable paging files like
we have in netbsd today.

the anonymous-space version doesn't have any real advantage over the
growable file scheme as far as I'm concerned, but the ability to
lazily allocate the backing store for paging space from the filesystem
is pretty cool.  the mach scheme had hi- and lo-watermarks, so you
could guarantee a certain amount of paging space was always available
and also that a memory pig process wouldn't (necessarily) fill
your filesystem.  setting the watermarks to the same value resulted
in the current preallocation situation.

the notion of putting swap space near files currently in use is
interesting.  wouldn't this result in the space used for actual files
becoming fragmented by the little bits of paging space interspersed, tho?

as for keeping all of the info on paging space in a filesystem in memory,
would there be any advantage to doing that vs. just putting the paging space
in a file?  keeping it all in memory could consume considerable amounts
of RAM, especially if the space all in little pieces near currently used files.
a file containing paging space would survive a crash just as well as
any other file in the filesystem.

this is all a separate discussion from the previous subject tho, since
eager vs. lazy allocation of paging space to back virtual memory allocations
is only somewhat related to how paging space is allocated on disk.

-Chuck


Mike Cheponis writes:
> I think if we re-frame this, we end up witn a non-issue.
> 
> Firstly, the notion of "swap" is antiquated and has no purpose in an OS on
> the verge of the 21st century.
> 
> The correct way to do this, IMHO, is to use unallocated filesystem space
> as swap space.
> 
> The bit vectors that hold allocation status are in memory (as well as on
> disk).  When some disk space is needed for "swap" then only the in-memory
> allocation status vector is changed to reflect that some piece of the
> disk is "used" and can't be allocated by real files.
> 
> Since this is in-memory, it cleanly survives a crash, because on disk these
> parts used as "swap" are not shown as allocated.
> 
> This method has the further advantage that (on a disk that's not nearly
> full) you can often locate what I will call this "Dynamic Swap Space" near
> the data files that are being used, and therefore, minimize total disk I/O
> time compared with a fixed swap allocation scheme.
> 
> It -is- true, as in any buffer stacking situation, some run-amok process
> could request infinite DynaSwap space; in that case, pointing the kill -9
> at the next process that requests another page seems like a reasonable
> strategy.
> 
> Lastly, I think it's totally bogus on a VM system if I can't have an array
> that uses up the whole disk if I want, so the programmer has this abstraction
> of a Very Large Memory.  In braindead architectures like the i386, I'm
> probably limited to 4 GB, but in reasonable architectures, I don't see why
> there needs to be any other limit than available disk space.
> 
> -Mike Cheponis