> Could you try this patch to ufs_bmap.c instead?

> --- a	2004-12-10 22:05:47.000000000 +0000
> +++ b	2004-12-10 22:11:55.000000000 +0000
> @@ -1,4 +1,4 @@
> -/*	$NetBSD: ufs_bmap.c,v 1.28.2.1 2004/07/28 11:29:42 tron Exp $	*/
> +/*	$NetBSD: ufs_bmap.c,v 1.29 2004/05/25 14:55:46 hannken Exp $	*/
>  
>  /*
>   * Copyright (c) 1989, 1991, 1993

Well, the base ufs_bmap.c I'm working with is 1.28.2.2; the patch
doesn't apply totally painlessly as a result.  But only the first two
hunks, which just update ID lines, fail; the rest of the patch _does_
apply cleanly.

The resulting kernel seems to work as well as the one with my own
patch, which is to say, in every test I've done, it Just Works, just as
if the filesystem were smaller than 1TB.  The most thorough test is to
create a 16GB file of random junk (/dev/zero encrypted with arc4) and
make copies of that until the filesystem is out of space.  Then check
that all the copies have the same contents.  (While it's possible in
principle that there is now a bug that reads other blocks off the disk,
it seems unlikely to the point of ignorability that it happens to get a
wrong block with the right contents every time, when reading well over
100G of data.  As for the original bug, I cannot postulate a mechanism
that would arrange for the memory pages to just happen to contain the
right random-looking data every time, over more than 100 times as much
data as the machine has RAM.)

Thus, I consider either patch to be a fix as far as behavioural
characteristics are concerned.  Based on the log message quoted a ways
upthread, this may break LFS (does it use the code from ufs_bmap? I
know it shares _some_ code with UFS).  While I expect NetBSD to care
about that (and rightly so), for the purposes this machine is intended
for, we don't.

In passing, is there any way, under the new world order for builds, to
do an incremental build of a kernel?  build.sh appears to be the only
supported way to build parts of the OS now (or have I misunderstood?),
and its kernel= facility appears to always recompile the whole thing
from scratch.  On the machine in question this is tolerable - it's a
fast Xeon - but on anything much less than that it would be intolerable
to rebuild everything when replacing just one .c file.  I believe
something needs fixing here, though what it is depends on whether I
have misunderstood.

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