>> This fix actually does not fix my problem at all.  Looking at the
>> greater context, this is not surprising, because this function is
>> called only when new blocks are being allocated.  My problem strikes
>> when reading existing, valid (per fsck), on-disk data structures.
> That doesn't really necessarily follow from the description I've seen
> of the problem.  If the blocks are scrambled when writing, you'll of
> course get the wrong thing back when you read.

Yes.  But (a) fsck is happy with the filesystem and (b) I have on
occasion gotten different things back from two consecutive mounts with
no filesystem-api-level changes made to the filesystem at all between
the two reads.  In one case I am fairly sure the data obtained by
reading the directory with cat was not on the disk _anywhere_.

Of course, (b) is not, strictly, inconsistent with the theory that
things are getting garbled on write.  But I prefer to posit one bug
rather than three, at least tentatively.  (I say "three" because we
have (a) the bug that garbles on write, (b) the bug that garbles
(differently, note) on read, and (c) the bug in fsck that makes it
happy with the filesystem despite the damage from (a).  My own tests
using /dev/* access to the disk have convinced me that that access
channel is clean above the 1TB point - possibly only up to the 2TB
point, I can't check that, but certainly for the whole "disk" I'm
working with.)

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