david@walking.pub.uu.oz.au (David Le Blanc) (12/17/90)
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. -----