Subject: Re: swapfs and uvm.
To: Bill Sommerfeld <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 03/15/2000 06:13:24
Bill Sommerfeld wrote:
> > * Perhaps later on using some sort of tree for directory entries.
> > Maybe not an issue - how big to directories grow on /tmp?
> The top-level directory in /tmp gets fairly large on some systems.
> Maybe a hash table?
Sounds reasonable - for v2 :-)
> > * Is it possible to release individual pages in an aobj back to the
> > system? This is one of the major problems with the current mfs (as
> > well as copying data multiple times). If not, is there another sort
> > of uvm object that might be better suited to a swapfs?
> I think someone else suggested implementing it as one aobj per file.
> I think this would be a better approach..
> (among other things, it makes things like mmap of files in /tmp
> potentially less painful..)
The idea crossed my mind, but this raises a few more (to my mind
* How quick is the process of creating an aobj?
* Is there some kind of limit and/or performance impact of having lots
of aobjs? This would seem to be a function of how well the pool
allocator can handle the load, and thus each aobj structure would
live in wired kernel memory. This maybe even could lead to a DOS
attack if the circumstances were right and someone created lots of
files in the swapfs.
* From an mmap POV, would this limit the maximum size of a file to the
size of swap (think sparse files)?