dwl10@uts.amdahl.com (Dave Lowrey) (05/05/90)
What exactly are disk "keys"?
I am having some problems with my hard drive, and need some help figuring
out what exactly is happening.
I have an A2500, 2909A controller, and a 43+Meg Rodime hard drive.
A week ago, I got the dreaded "Disk Read/Write error" requestor. I
had recently done a backup, so I formated the partition, and
re-loaded the data.
To be sure that all was OK, I ran disksalv against the partition, and
it came up with several "Block Key Mismatch" errors.
To make sure it wasn't my backup program (quarterback), I re-formated
the partition, and installed Lattice 5.0. Disksalv again found several
"Block Key Mismatch" errors. This time it was different blocks.
I then took my drive, and low level formated it on a PC. The format and
verify went clean. I therfore don't think the problem is a media error.
The "Bad" blocks are consistant, in that the same block number is "bad"
whenever I do the same load. If I re-install Lattice, after restoring
the rest of the disk, I still get some new "Bad" blocks, but in a different
file.
The really weird thing is that the supposedly "bad" files can be read! No
data appears to be missing, and no errors occur when I access the file.
Now for my questions.....
What exactly is a "Block Key". I assume it is written when the disk is
formatted. Are they ever re-written?
Is there a utility that I can use that displays the keys? Can they be
"fixed" so that they are correct?
Is disksalv maybe giving me "false" errors?
Any ideas on what to do next?
--
"This ain't Rock 'N Roll, | These be my words, not my employer's!
this is Genocide!" |Dave Lowrey - Amdahl Corp. - Houston, TX
David Bowie - |In Texas: {moray,uhnix1}!starsoft!david
"Daimond Dogs" |The World: dwl10@uts.amdahl.com (amdahl!dwl10)dwl10@uts.amdahl.com (Dave Lowrey) (05/05/90)
In article <37SF02dNa4kc01@amdahl.uts.amdahl.com> dwl10@uts.amdahl.com (Dave Lowrey) writes: Well, after some research, I am able to answer some of my own questions! I fond a back issue of transactor that explained the FFS (and OFS) format. >What exactly are disk "keys"? > They live in a "file header", which describes a file. The key is really the block number of the header. >I am having some problems with my hard drive, and need some help figuring >out what exactly is happening. > >I have an A2500, 2909A controller, and a 43+Meg Rodime hard drive. > >A week ago, I got the dreaded "Disk Read/Write error" requestor. I >had recently done a backup, so I formated the partition, and >re-loaded the data. > >To be sure that all was OK, I ran disksalv against the partition, and >it came up with several "Block Key Mismatch" errors. > >To make sure it wasn't my backup program (quarterback), I re-formated >the partition, and installed Lattice 5.0. Disksalv again found several >"Block Key Mismatch" errors. This time it was different blocks. > >I then took my drive, and low level formated it on a PC. The format and >verify went clean. I therfore don't think the problem is a media error. > >The "Bad" blocks are consistant, in that the same block number is "bad" >whenever I do the same load. If I re-install Lattice, after restoring >the rest of the disk, I still get some new "Bad" blocks, but in a different >file. > >The really weird thing is that the supposedly "bad" files can be read! No >data appears to be missing, and no errors occur when I access the file. > >Now for my questions..... > >What exactly is a "Block Key". I assume it is written when the disk is >formatted. Are they ever re-written? > See above for description. They are created when the file header is create I assume they are re-written if the header is updated. >Is there a utility that I can use that displays the keys? Can they be >"fixed" so that they are correct? > Yes, I used "disked" from the software toolkit. They keys can be changes, as they are just data in a sector. >Is disksalv maybe giving me "false" errors? > Yes and No. Here is what I found out: There really are bad headers on the disk. However, these headers are NOT part of the filesystem! They are lone sectors, sitting on the disk that have header info in them, but are never referenced. Since the disk was clean before I reloaded the software, I have no idea of where these headers came from. No files should have been deleted during re-load, so why are they there????? Any ideas ????? -- "This ain't Rock 'N Roll, | These be my words, not my employer's! this is Genocide!" |Dave Lowrey - Amdahl Corp. - Houston, TX David Bowie - |In Texas: {moray,uhnix1}!starsoft!david "Daimond Dogs" |The World: dwl10@uts.amdahl.com (amdahl!dwl10)
trebbien@cbmger.UUCP (Uwe Trebbien GERMANY) (05/08/90)
In article <62Gj02bea4fI01@amdahl.uts.amdahl.com> dwl10@amdahl.uts.amdahl.com (Dave Lowrey) writes: >Yes and No. Here is what I found out: > >There really are bad headers on the disk. However, these headers are >NOT part of the filesystem! They are lone sectors, sitting on >the disk that have header info in them, but are never referenced. Thats ok. Because they are never referenced only a diskmonitor is able to find them and will give you that bad key message. >Since the disk was clean before I reloaded the software, I have no >idea of where these headers came from. No files should have been >deleted during re-load, so why are they there????? > >Any ideas ????? I think while formatting there are several bit patterns written to the disk. It is possible, that the patterns are not the same for the whole disk, using e.g. incremental values, so that some blocks are interpreted as file headers. Other possible reason is that directory blocks and bitmaps are updated several times during reload. You may get this bad key message whenever a block is referenced by two different headers. Since only one header is valid the file system won't worry, but a disk monitor will find that second reference. best regards UWE