>> I didnt dare try an ffs with 1meg blocks and 128k fragments and
>> 2-block readahead: would that have worked?
> I just now tried it on a 100MB filesystem in a vnd and newfs cored on
> me.  I'm going to investigate further.

Found it.

The blocksize must be no greater than MAXBSIZE, but newfs doesn't check
this.  Instead, it cheerfully overruns its internal buffers and one
part of the code stomps on things another part has set up.

Building newfs with -DMAXBSIZE=1048576, I got a newfs that ran,
apparently happily, and presumably built a filesystem.  fsck was not
happy, claiming "BAD SUPER BLOCK: SIZE PREPOSTEROUSLY LARGE".  I didn't
try mounting it; there's a comment in param.h (where MAXBSIZE is
defined by default) saying that MAXBSIZE "may be made larger without
any effect on existing file systems; however making it smaller may make
some file systems unmountable".  (The default is MAXPHYS, which is
port-specific; the tree I have has values from 32K to 128K, with most
of them at 64K.  alpha and i386 have an #ifndef that appears to imply
you could "options MAXPHYS=...." in the kernel config to raise this,
but that won't affect userland; you'd probably have to change the
arch's param.h and rebuild the affected userland pieces to get a fully
consistent system.  I wonder if MAXPHYS and/or MAXBSIZE should be
readable by a sysctl, so userland doesn't have to depend on a #define?)

/~\ 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