mark@oscvax.UUCP ( former OSS student) (07/15/88)
A friend of mine is using a Western Digital 32meg drive on an A2000
with a bridgecard. The drive has been operating fine for months, but lately
will not validate on bootup. A few minutes after the system boots, a
a system message appears: KEY 24239 ALREADY SET. Block 24239 happens to be
a directory header block.
Data can be read from the drive, but writing is not allowed since the drive
is not validated. Attempts at fixing the root block with a block editor
have not been allowed either.
Does anybody have any ideas on how this occurred? Can the drive be fixed
without having to reformat?
Thanks in advance,
Mark Bariciak
... ihnp4!utzoo!oscvax!markpage@swan.ulowell.edu (Bob Page) (07/18/88)
>KEY 24239 ALREADY SET. Block 24239 happens to be a directory header block. It means more than one block 'claims' it uses the block. For example, a file might say 'one of my data blocks is 24239' or a directory says 'one of my file header blocks is at 24239' while some directory says 'one of my subdirectory blocks is 24239'. The validator doesn't like this. >writing is not allowed since the drive is not validated. This is what you want. >Attempts at fixing the root block with a block editor have not been allowed What program are you using? Most (if not all) disk editors bypass DOS and talk directly to the device, which has no idea about filesystem layout. >Can the drive be fixed without having to reformat? Yes. You have to find the multiple references to the block. Probably the best way is to write a program to scan each block, and look to see if it claims to have 24239 (0x5EAF) as a neighbor (parent, child, next data block, etc). If so, print the block number to the screen, then use a disk editor later to look at all those blocks and find the offending block(s) (hopefully you'll only have one) and fix it. Of course there's a lot of filesystem wizardry at work in the last paragraph, and unless you know what you're doing (or are willing to learn) your best bets at this point are: 1. reformat the disk and restore from your last backup 2. send your disk & controller to somebody who will fix your filesystem structure for you (hmmm ... maybe I should start a FS reclamation consulting service :-) 3. beg Dave Haynie to release his version of Disksalv that works with hard disks. It would also be nice if the validator helped you out here by telling you WHERE the duplicate references were, since it already has the information. Maybe in KS 1.4. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "What a wonder is USENET; such wholesale production of conjecture from such a trifling investment in fact." -- Carl S. Gutekunst
steveb@cbmvax.UUCP (Steve Beats) (07/20/88)
In article <8132@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >>KEY 24239 ALREADY SET. Block 24239 happens to be a directory header block. > >[stuff deleted] > >It would also be nice if the validator helped you out here by telling >you WHERE the duplicate references were, since it already has the >information. Maybe in KS 1.4. > >..Bob >-- >Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Actually, the validator doesn't have the information. Validator works by building a bitmap for a disk that doesn't have one because of a crash or power was turned off before the bitmap was written. Under the 1.2 filing system, it's also possible to fill a disk with user data thus leaving no room for the bitmap blocks on the disk so the bitmap has to be constructed then too. Validator maintains two bitmaps while it is running, one is a visit map that tells validator which headers are referenced by other headers and the other is the physical bitmap it is building. Since there is only one bit set in the visit map for each header referenced, there is no way to tell which headers have the conflicting entries. This is VERY likely to change for 1.4 (a little bird told me :-) Steve
page@swan.ulowell.edu (Bob Page) (07/21/88)
I wrote: >It would also be nice if the validator helped you out here by telling >you WHERE the duplicate references were, since it already has the >information. Maybe in KS 1.4. steveb@cbmvax.UUCP (Steve Beats) replied: >Actually, the validator doesn't have the information. Not at the time it detects the duplication, but it *did* have it, just threw it away. >This is VERY likely to change for 1.4 (a little bird told me :-) Great. It only needs to go into this verbose mode if a bitmap collision occurs... you'd just rescan the disk looking for references to the block you know is referenced more than once. Otherwise, assuming every block might have multiple references would make you construct a huge (depending on partition size) owner list for each referenced block, clearly a waste of memory. I think extended error messages in 1.4 will be perceived as just as large an improvement in the file system as FFS is in 1.3. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "What a wonder is USENET; such wholesale production of conjecture from such a trifling investment in fact." -- Carl S. Gutekunst