Path: utzoo!attcan!uunet!van-bc! From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga Subject: Re: HD Problems (& maybe solutions) Message-ID: <1665@lpami.wimsey.bc.ca> Date: 30 May 90 23:23:17 GMT Lines: 80 Return-Path: To: van-bc!rnews In <20679@snow-white.udel.EDU>, jones@uv4.eglin.af.mil (Calvin Jones, III) writes: >Fred Fish writes (In response to Dale Luck's query > about HD problems): > >> Well, given the following assumptions about the disk layout (which >> I believe to be close to reality :-): >> >> (1) The root block for each partition is exactly in the >> middle of the partition and can be identified by >> it independent examination of each block. >> >> (2) There is a small reserved area at the beginning of the >> disk for the RDB stuff. This is of known or determinable >> size. >> >>Thus a disk with three partitions would be laid out as: >> >> RDB A0 A A1 B0 B B1 C0 C C1 >> >>where >> >> RDB is a known size >> A, B, and C are the root blocks and are at known offsets >> A0,A1 B0,B1 C0,C1 are of unknown size >> >I fear it's not so simple. Some drives/controllers do *NOT* use the RDB >(C-Ltd, for instance). Not all products support RDBs, but the idea of finding the extent of the partitions this way is a good one, and should be relatively easy to do. One would scan for both root blocks and possible 'reserved' blocks. The latter would contain the file system type in the first longword. Calculation would find the last block of the partition. In all cases, barring bad data that mungs a root block and a 'first block' of a partition, the atual partition sizes could be recovered. >An additional problem is that you may not have any idea about the number >or size of partitions on the disk. Well, that's what a program of this type would do for you; find and report the partitions by size. > Some controllers also allow the use >of different descriptions of partitions on one drive since the SCSI >drives end up just using a block number rather than needing the actual >cylinder, head, and sector. Translation is not difficult, provided the user at least knows the geometry of the device. >It sure would be nice if we had a nice little utility that could figure >all this info out on any random HD connected to an Amy. > >And then it could figure out what to do about the "Key Already Set" >requestor! That one is also do-able, though it isn't trivial. The way the validator works now is: If the bitmap is invalid, scan the entire directory structure. For each block shown as used in the header blocks, put an entry into a bitmap, after checking to make sure that the bit shows that block as unused. If it finds one that is already used, report the dreaded "Key nnnn already set. The way to find out what two entries are pointing at the same place is to write a program that does the same thing, but instead of stopping when it finds a key already set, have it remmeber the key, and start the scan over again, looking for that same key. When it is found, report the two files/directories that are pointing at the same block, and report them, optionally allowing you to recover on the spot, or with a sector editor. -larry -- The raytracer of justice recurses slowly, but it renders exceedingly fine. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+