lphillips@lpami.wimsey.bc.ca (Larry Phillips) (05/31/90)
In <20679@snow-white.udel.EDU>, jones@uv4.eglin.af.mil (Calvin Jones, III) writes: >Fred Fish <fnf@fishpond.uucp> 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 | +-----------------------------------------------------------------------+
jones@uv4.eglin.af.mil (Calvin Jones, III) (06/01/90)
Fred Fish <fnf@fishpond.uucp> 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).
An additional problem is that you may not have any idea about the number
or size of partitions on the disk. 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.
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!
--- Cal
// Cal Jones - Internet: <Jones@UV4.Eglin.AF.Mil>
\X/ BBS: 904-243-6219 1200-9600HST 340Meg, all Amiga
Single Tasking? *JUST SAY NO!!!*
Home of MechForce Support.lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/01/90)
In <20799@nigel.udel.EDU>, new@udel.EDU (Darren New) writes: >In article <1665@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>Calculation would >find the last block of the partition. > >One should keep in mind that there are partitions with odd numbers of sectors. >More than one disk utility fouled up the calculation and munged a disk. >I don't know what the answer is, but it seems clear that there will always >be at least two different size partitions with the same root block offset. > -- Darren Ahh.. forgot about that one (dunno why, it's bitten me before). I don't think there's be a problem calculating it though, provided you remembered what you told the prep program the geometry was when you formatted, since the partition will always end on a cylinder boundary. -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 | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (06/01/90)
In <8fgk02eUab6S01@amdahl.uts.amdahl.com>, dwl10@uts.amdahl.com (Dave Lowrey) writes: >In article <1665@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>In <20679@snow-white.udel.EDU>, jones@uv4.eglin.af.mil (Calvin Jones, III) writes: >>>Fred Fish <fnf@fishpond.uucp> writes (In response to Dale Luck's query >>> about HD problems): >> >>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. >> >Be carefull with this one! Yup... definitely needs sanity checking. >I went on for several weeks thinking my HD or controller was bad, when >they really wern't.. > >Disksalv was coming up with some "bad header blocks". These were headers >that pointed to valid files. However, I found out that the headers >themselves were never pointed to by a "directory". > >Fo some reason, these invalid, but never referenced, headers were being >created by DOS when I restored my freshly formatted HD. There were >only about 3 of them (out of several thousand files), but they caused me >alot of grief until I figured out what was going on. Can't see how they were being created by the Dos, but they could certainly have been parts of files that were restored. -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 | +-----------------------------------------------------------------------+
new@udel.EDU (Darren New) (06/01/90)
In article <1665@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Calculation would >find the last block of the partition. One should keep in mind that there are partitions with odd numbers of sectors. More than one disk utility fouled up the calculation and munged a disk. I don't know what the answer is, but it seems clear that there will always be at least two different size partitions with the same root block offset. -- Darren
dwl10@uts.amdahl.com (Dave Lowrey) (06/01/90)
In article <1665@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <20679@snow-white.udel.EDU>, jones@uv4.eglin.af.mil (Calvin Jones, III) writes: >>Fred Fish <fnf@fishpond.uucp> writes (In response to Dale Luck's query >> about HD problems): > >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. > Be carefull with this one! I went on for several weeks thinking my HD or controller was bad, when they really wern't.. Disksalv was coming up with some "bad header blocks". These were headers that pointed to valid files. However, I found out that the headers themselves were never pointed to by a "directory". Fo some reason, these invalid, but never referenced, headers were being created by DOS when I restored my freshly formatted HD. There were only about 3 of them (out of several thousand files), but they caused me alot of grief until I figured out what was going on. -- "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)