For what (little :-) ) it's worth, I got bit by this too. Ultimately it
boils down to the problem that once the on-disk file system is sufficiently
broken, the journal doesn't have enough information for fsck to even detect
the problem, much less fix it.
(In my case the problem most likely was
In src/sys/amd64/include/vmparam.h is this handy map:
* 0x - 0x7fff user map
* 0x8000 - 0x7fff does not exist (hole)
* 0x8000 - 0x804020100fff recursive page table (512GB slot)
* 0x804020101000 - 0xfdff
(Apologies for delay in reply, family issues)
I'd be fine with 4 TB instead of 16; and, at this point, with the latest
patches, it's easily tuned. The auto-sizing of the direct map is not
affected by sparse space as it keys off Maxmem, which is not actually
physical size, but rather one past
(Apologies for google mail, I moved a while back and my office at home is
still not up and hence my regular FreeBSD machine at home is also not up.)
In Makefile.inc1 we have:
.if defined(DB_FROM_SRC)
INSTALLFLAGS+= -N ${.CURDIR}/etc
MTREEFLAGS+= -N ${.CURDIR}/etc
.endif
which is fine as far as
