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
hairier) questions:

 * 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)?

Simon.