Eduardo E. Horvath wrote:

> > Here's some rough notes on how I think a swapfs filesystem should be
> > implemented from a layout POV.
> > 
> >  A- The filesystem size will be limited to 2^32 512 bytes "blocks", as
> >     this is how big the size parameter is (on 32 bit machines anyway),
> >     and I've kept the size parameter in terms of 512 bytes blocks since
> >     that matches what mfs uses.  Page offsets internally are u_int32_t's
> >     so there's an absolute maximum filesystem size of 2^32 * PAGE_SIZE.
> >     I don't see the maximum filesystem size as a real limitation...
> 
> Wouldn't paddr_t or psize_t be more appropriate than u_int32_t's?

The reason I chose a u_int32_t was so that I could fix the inode size to
something that was a power of two so it would pack nicely into a page.
These were not going to be pointers to pages, just page offsets from the
start of the aobj.  Reserving room for up to 64-bit types and padding
against a union of N u_int64_t's effectively doubles the inode storage
or cuts the number of direct blocks by over half.

Perhaps a larger inode would be ok - if we had say 256 byte inodes and
some smarts to store files shorter than say 192 bytes in the inode
(sorta like short symlinks) we may get some wins.

A quick check of a few filesystems (/, /usr, /var on a NetBSD and an
Ultrix box) around here show that of 89201 files, 9414 are greater than
0 bytes and less than 192 bytes, and 1180 zero length files.  So in this
case using 128 byte inodes and 1k fragments we use approx 20.1MB for all
inodes and file contents less that 192 bytes and using 256 byte inodes
with an up to 192 byte payload we use approx 21.8MB.  Hmm, a little
behind and probably not worth the extra complexity.

Obviously a /tmp type filesystem is going to have different usage
characteristics - does anyone have a well-used /tmp that they can run
the following on?

	df -i /tmp ; find /tmp -size +0 -size -192c -ls | wc -l


Maybe small payloads is still worth looking at.  In the above
filesystems, there's 5728 files that are > 0 and < 68 bytes, which
would effectively save that many fragments/pages/whatever...

Simon.