> anon-space (I call it DynaSwap) allows VM to use as much or as little of
> the disk as needed; this seems like a significant benefit.

Once we would be able to delete swap files, you can pretty
easily emulate your "DynaSwap" behaviour even with userland
daemon -- allocate new swap files when we are short of memory
and delete old ones when they are not needed.

I DO prefer swap partitions (if only they're necessarily much faster) --
I always though about swapping to files as "temporary-until-real-swap-
is-available" thing.

> I remember only vaguely some of the Mach stuff, and I do recall
> a really good team worked on it, and they had plenty of decent ideas.
> I wonder why they abandoned dynamic swap space?

My guess is the VM code got too hairy and it wasn't performant
enough anyway.

> I think this would be OK, especially if once the process using the pages
> finishes, and the space becomes deallocated.  A background defragger can
> then defrag the file.

However, we need not restrict ourself to single user machines only
and we need to count with processes NOT finishing within reasonable
amount of time ;-) -- we are not MS-DOS ;-)

> You're of course right that for huge processes the in-memory bookkeeping
> could be substantial, because it would use not only the allocation bit
> vector but tables of page table assocations.  Clearly, -this- info must
> be able to be swapped out if necessary, too.

I'm not very sure swapping out swap metainfo would be possible
without really nasty hacks.

Ad auto-defragmenter -- defragmenter is old technology  ;-)
Anyway, IMHO it's not very wise having it
running in multiuser mode. Having it available (perhaps as
part of fsck) would be cool though.

"The Right Way"(TM) of doing things is designing system so that
defragmentation is not necessary for normal OS operation.

-- Jarda