kern/44629: tmpfs filesystem improperly sized

[cross+netbsd%distal.com@localhost]

>Number:         44629
>Category:       kern
>Synopsis:       tmpfs filesystem doesn't obey -s size argument
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 23 16:35:00 +0000 2011
>Originator:     Chris Ross
>Release:        NetBSD 5.99.45
>Organization:
>Environment:
System: NetBSD skaro.distal.com 5.99.45 NetBSD 5.99.45 (GENERIC) #0: Mon Feb 7 
17:55:57 EST 2011 
cross%skaro.distal.com@localhost:/data/obj/NetBSD.i386/data/NetBSD/src/sys/arch/i386/compile/GENERIC
 i386
Architecture: i386
Machine: i386
hw.physmem = -268959744
hw.usermem = -275025920
hw.physmem64 = 4026007552
hw.usermem64 = 4019941376
>Description:
On my 4GB RAM i386 machine, I cannot get sufficiently large tmpfs filesystems.
The -s argument doesn't allow me to size the filesystem beyond a certain mount,
which varies, but is usually between 130MB and 500MB.  This size also can change
while the system is operating, occasionally shrinking or growing.

My fstab includes:

tmpfs           /tmp            tmpfs   rw,-s=600m
tmpfs           /var/run        tmpfs   rw,-s=5m

...but the following is the state of the above filesystems.

Filesystem   1K-blocks       Used      Avail %Cap Mounted on
tmpfs            211520         24     211496   0% /tmp
tmpfs              5120        152       4968   2% /var/run

I've tried larger and smaller -s values, and excluding the -s argument
completely.  In each case, the filesystem appear to be maximally the same
size (but a number that is inconsistent) for each attempt within a session.
Setting the -s argument value to a small number does sucessfully limit the
filesystem size to that value.
>How-To-Repeat:
Boot a machine that's affected, with a tmpfs filesystem specified that's larger
than a few hundred megabytes.  I suspect that my being on a 32-bit machine with
exactly 4 GB of memory is a core part of the problem, but I have not yet
tested this.
>Fix: