[rumble@ephemeral.org]
> [mouse@Rodents.Montreal.QC.CA]
>> Is 247M anywhere near any of your per-process resource limits, by
>> any chance?
> Apparently proc.curproc.rlimit.{datasize,stacksize}.{soft,hard} =
> 268435456.

256M.  Allowing 9M for various random bits & pieces comes out to 247M,
so that's likely it.

> These cannot be altered, neither increased nor decreased.  sysctl
> takes values without complaint, however upon checking them again,
> they appear unchanged.

mrg already pointed out what is probably going on here - sysctl is
changing the proc.curproc values, which apply to the process doing the
changing - the sysctl process.  Then that process dies, and its changed
values die with it.  You then run sysctl again to check, and it
inherits the values from your shell, values which didn't change....

Try

	sysctl -w proc.$$.rlimit....

instead of

	sysctl -w proc.curproc.rlimit....

The shell will expand $$ to the shell's own PID, before running sysctl,
so the change (if it works) will affect the shell, and thus further
commands run by that shell too.

> Although it's rather pointless to do so, the 64mb machine can mount a
> 512mb mfs without issue.

Well, until you fill it up beyond the amount of free RAM lying around,
at which point it starts swapping.

> Do you happen to know how datasize.hard is limited?

Unless the above explanation of sysctl helps, no, I don't.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B