🚀 go-pugleaf

Earlier I wrote :

> I have just prepped/formatted my A590 internal harddrive, and copied about
> 16 Meg from my second drive. Now, when I type 'cmp all hd0: dh0:' it shows
> that *TWO* files are corrupt. By all coincidence I have *TWO* bad blocks
> on the drive. (Which *appear* to be mapped out properly..)
> 
> I ran a sector editor, and traced the corrupt files. It seems that both
> hit *BAD* blocks, and when they do, the drive zips a fair way (from the
> noise it makes) and reads a different block. (probably what the corrupt
> block is mapped to?)
> 
> Now, doing a '*verify* disk' turns out the following info
> 
> 'bad block recovered at 39434 (track 730, sector 2 head 0 block 39422)'
> 'bad block recovered at 39488 (track 731, sector 2 head 0 block 39476)'
> 
> Now judging from these mappings, I wouldnt expect the drive head to have
> to move at all to reach the remapped sectors.
> 
> Now, in ALL cases of corruption, the file had *ONE* block replaced with
> that from another file that was copied on AFTER.
> 
> The conclusion?
> 
> For each BAD block, the data is written to the WRONG place entirely, and
> eventually written OVER by files written later to the disk, since the
> block that the data *IS* eventually written to, is not allocated in the 
> bitmap.
> 
> What I would like to know (as well as how to fix this stupid problem)
> is how a bad blocks handled (when handled properly). I find it hard to
> believe all bad blocks are mapped to somewhere else on the disk, because
> you would run out of room! And if the bad block is marked in the bit map
> as a bad block, is it then a file system record? or does the drive
> keep record of the bad blocks? and if so, where? (after all, its all taken
> up for data!, except the first two blocks used by the file system..)
> 
> basically, HELP!
> 

Since then, I edited the bad block list, and deleted BOTH bad blocks. I then
created two single byte files, and using a disk editor, changed each file
to point to a bad block (Then forced a re-validate).

I then copied 18 Meg onto the drive, it *ALL* compared ok, copied another 
two meg on to fill the disk up to 4 blocks free, compared the new data, and
then re-compared the old data (the first 18 Meg) and there was absolutely
 *NO* corruption of the files.

I then did a *QUICK* format to remove the dummy files and all other
contents, and again filled the disk. This time, with the bad blocks as
fair game to the file system. Again *NO* corruption. (I know the Blocks
are in fact dodgy, just not entirely unreliable :-))

Question : Why is this so? Why does mapping out the bad block cause problems?

Question : Why did the file system have *NO* trouble with blocks that
           *verify data* found were defective? (If they were not mapped out.)

Question : What phase is the moon in, and could it have affected the results?

Question : How does a drive map out bad blocks, and how does this affect
           the filesystem trying to write to those blocks?

Well, I am going to put the dummy files back for now, and pretend the drive
works... Till some answers come!!

BTW: I have *updated* the filesystem to the 1.3.2 FS (12248 bytes) and
     changed the version to *36* (ie non-zero) but none of this helped.
	 (I havent checked if location zero has been corrupted either:)

 ----------------------------------------------------------------------------
    David Le Blanc    UUCP (home)   : eyrie!walking!david@labtam@munnari.oz
    david@walking     ACSNET (work) : david@dogmelb.dog@munnari.oz
                                      CSIRO Division of Geomechanics
    "Life? Dont talk to ME about life.. " :  Marvin the paranoid android.
 -----