Subject: Re: kern/32701: [dM] Indirect blocks break on big filesystems
To: None <,,>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: netbsd-bugs
Date: 02/03/2006 08:45:02
The following reply was made to PR kern/32701; it has been noted by GNATS.

From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: kern/32701: [dM] Indirect blocks break on big filesystems
Date: Fri, 3 Feb 2006 03:35:55 -0500 (EST)

 Update on my "large filesystems vs indirect blocks" issue....
 I did a search on my test filesystem, looking to see if maybe indirect
 blocks just got written to the wrong place.
 First, I made up a list of the blocks the on-disk filesystem pointed to
 for the last-written test file.  The single indirect block was full of
 0s, causing one indirect block's worth of data to be missing from that
 view of the file.
 Then, I searched the filesystem for a distinctive string that was
 present in every block of the file (I wrote the files with a program
 designed to produce such distinctive content).  This gave me a list of
 every block containing file contents.  All the missing data blocks were
 actually present on the disk.
 Then, knowing their numbers and (from their contents) where they
 belonged in the file, I worked out a small (16-byte) snippet of what
 the lost indirect block's contents would be.
 Then, I searched the entire partition for that 16-byte string.  That
 search just completed, and it found nothing at all.  So either the
 indirect block never got written, or it got overwritten by something
 else later.  (I consider the former a great deal more likely,
 especially since all the data I've looked at (which is admittedly just
 a few spot checks) are consistent with the theory that indirect blocks
 are lost when their disk sector numbers, treated as 32-bit signed
 numbers, go negative.)
 Now to try a newfs plus write tests under a 3.0 kernel....
 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B