Hi everybody,

I've been stress testing tmpfs today after all the fixes that have got
in since it was imported (thanks yamt@!).  Stability has improved a
lot from my POV, so I wanted to share this with you to see if you feel
brave enough to start using it :-)

First of all, I mounted an automatically-sized tmpfs on my test
machine: 32MB ram, ~64MB swap.  I started by unpacking a pkgsrc
tarball over it, which didn't finish due to space being exhausted.
tmpfs correctly handled the errors and it was able to delete the
incomplete tree without problems.  (There used to be a problem in
the string management that left a file with a zero-length name which
wasn't unremovable.  Fixed now.)

Then, on this same machine I built some packages with /tmp over
tmpfs and without using gcc's -pipe.  I also set WRKOBJDIR to
/tmp/pkgsrc and had no problems.

As this machine is really short on memory to do serious tests, I
switched to my main machine, which has 1GB ram and 2GB swap.
Two weeks ago or so, extracting pkgsrc over this resulted in a
reproducible crash half away the process.  I've now been able to
unpack the whole pkgsrc tree successfully (which took less than
10 seconds :-).  After this, I ran diff -ru over the new tree and the
one on ufs (thanks to perry@ for the suggestion) to ensure that
everything was correct.  And it was, as diff was completely silent.

Then I built a toolset using build.sh -M /tmp/obj and, as above,
without the -pipe option.  This went fine (FSVO fine, because the
tools seem to be broken ATM); I later tried with 3.0 tools which
finished successfully.  I'd like to try building something bigger
(like the whole system), but that won't be today.

At last, there used to be a problem when exporting a tmpfs over
NFS: if you created a file on the real file system and then read it
through NFS, it crashed the machine.  This has gone away too, but
NFS support is still broken WRT the readdir operation.  It easily gets
out of sync; dunno why yet.

Tomorrow I'll see if I can do a preliminary implementation of a pool
allocator that uses anonymous memory rather than kernel wired
one.  It shouldn't be too hard if the idea I've in mind is workable.

Let's switch your MFS stuff to tmpfs!

--
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/