Jump to content
Posted 22 October 2015 - 06:37 PM
Posted 22 October 2015 - 09:39 PM
My guess is you might have a problem with CHS translation. Since the system can only see the drive as 8.4GB, we can assume the BIOS does not implement true LBA, only translation, but the larger of those cylinder parameter combinations exceeds the limit of cylinder numbers under CHS translation, which is 16384. 16383/16/63 is a valid combination, 17475/15/63 is not.
CHS translation can be a cranky beast. You can have trouble if you connect a drive to a mainboard that uses a different system of CHS translation, or if you use the drive with an OS that doesn't understand CHS translation. Also, if the CHS translation system being used is done by bitshifting, it can experience the Phoenix bitshift bug, which allows parameters to be oversized, but if those locations are written to, the addresses wrap around and the data is written at the offset from the start of the drive instead of the end. Since you don't seem to have indication of substantial data corruption, I suspect that's not the problem,
Since you can identify a likely starting point as being use of a file recovery program, we could suspect it or its operating environment if it involved booting into a different host OS, did not handle CHS translation correctly. I suppose there's a vague possibility the cluster size of the G: partition, which is non-standard for earlier implementations of FAT16, could confuse a utility, but I'd expect that to affect that partition, not another one.
The partition designations make sense for the problem you're having. BIGDOS just describes a DOS4 partition that can be larger than 32MB. Assuming the 3 partitions were created as primary partitions, if the middle one that mounts as F: gets marked as an extended partition instead, its partition table location will then be expected to hold a pointer to its own extended partition table, which will not exist, so it will appear corrupted. If the problem is caused by identification of partition type alone, we could guess that changing the type back should make it revert. I can't guarantee it though! Unfortunately the only way is probably to try...
If that solves the immediate issue, I'd suggest you will probably have ongoing trouble if you keep using the drive in similar circumstances. Drives using CHS translation in that interim phase were known to get upset about anything changing in a system from how they were initially set up. Some people even had their drives get corrupted from the BIOS backup battery going flat, and the BIOS forgetting its parameters.
Edit: If you, by whatever means, regain full access to the drive, I'd suggest one way to try to avoid having it keep happening. Copy off the drive contents temporarily (assuming none of the partitions are bootable), change the setting for that drive from AUTO to manually entered parameters, and re-partition and reformat the drive using the manual setup. Then copy the contents back. I do recall the AUTO mode being a little flaky on some BIOS, and it being safer not to use it if practical. If the drive has its correct CHS parameters printed on the label, use those. Some BIOS had, as well as the AUTO mode, an option in another menu to Auto Detect Drive - on those BIOS this was usually more dependable than using AUTO in the boot configuration, and if the drive isn't labeled, values returned by this facility if it exists would be the ones to use, in my experience.
Edited by Platypus, 22 October 2015 - 10:20 PM.
Posted 23 October 2015 - 03:54 PM
Thanks Platypus. Much of what you say makes sense.
My computer's BIOS must use true LBA mapping because these slave partitions work no matter which of the two configurations I use in the BIOS boot set-up... if I boot from Windows. The "Auto Detect Drive" is the auto feature I used. In my bios this is the only "auto" feature. On this particular slave drive, the first partition has an exact bit-for-bit copy of my Master hard drive. The other two partitions do not have bootable programs on them.
The problem, of course, with troubleshooting is that one always has to think back and guess what caused the problem. I'm beginning to think that those two DOS diskettes are the culprit for reasons you set out above. Question: so who is rewriting the partition boot sectors? DOS or BIOS?
I also discovered that when booting from the Dr.Dos disk that it somehow conflated my Master HDD c: drive and my Slave f: drive so that directories and files from both drives appear on the f: drive. My C: drive was fine. No corruption ensued when booting in Windows.
I assume that if I do change the MBR setting for a partition from EXTENDED to BIGDOS, I must also change the relative starting point in the drive's MBR. Extended slave drives don't start at this relative starting point, but instead start 63 sectors later. BIGDOS drives start exactly where they say they start.
Question: what is the difference between an EXTENDED partition and a later PRIMARY partition on a hard drive?
Posted 23 October 2015 - 07:49 PM
Without knowing the specifics of your system it's hard for me to offer more than educated guesses. Plus how long it is since I actually had to do any of this stuff... !
From what you've explained, it looks to me like your problem is that when the F: partition goes missing, what should be a standard DOS4 primary partition appears to be seen as if it is supposed to be a logical drive. That makes me suspect that the only thing that may have changed is the partition type designation, which will make the OS look in the wrong place. I have no clear explanation as to what would make this change, but I know from experience that for some reason it does seem to occasionally happen. That makes me hope that changing the type back to an ordinary BIGDOS primary partition would set things right, as an OS would then read the F: drive's MBR data as a partition table again, not as a pointer to a logical container that does not exist.
The only change required for that to happen is the drive type byte being 05h for an extended partition rather than 06h for the normal partition.
That link also mentions distinctions between the layouts & functions of the two partition types.
For the drive ID, if the BIOS runs true LBA, it should see the full drive size, unless that drive has the facility to clip, with a jumper that has been set to limit it to 8.4GB. Does the drive have its CHS parameters on the label, or can we find specs from brand/model?
If true LBA is not implemented, the effect of being able to set a parameter beyond CHS limits will depend on what method of CHS translation is being used. If it's being done by bitshift, and the value makes the drive capacity, say, 150MB too big, nothing abnormal will happen until the system tries to write something into that last 150MB space. The write will then occur at the start of the drive instead.
Edited by Platypus, 23 October 2015 - 08:04 PM.
Posted 24 October 2015 - 03:34 PM
Almost certainly a CHS mismatch.
Looking at the Drive's Master Boot Record, partitions 1 and 2 (Drives E and F, 32kb clusters each) have 256 sides, while partition 3 (Drive G, 64kb clusters) has only 240 sides. (side, cylinder, sector configuration).
The first two partitions each have their usual hidden 63 sectors. But Drive G has eight million or so hidden sectors - the size of the first two partitions combined.
Further, no matter how often I tell use the autodrive feature on bios and it picks the 16383/16/63 configuration, the system always bounces back to the invalid 17475/15/63 setting regardless of which OS system I use.
I suspect BIOS reads the the partitions in order and decides that the last Primary partition (Drive G) is the official configuration.
Booting with a DOS 6.21 disk and using the old Norton Diskeditor program, I discover that the second partition - the troubled F drive does not appear where "side, cylinder, sector" says it should. It does start at the correct physical sector, though. Partitions 1 and 3 (Drives E and G) do appear where they say they should according to physical sectors and side-cylinder-sector. I'm going out on a limb here, but I suspect that if I were to recalculate the side-cylinder-sector settings with the proper 16383/16/63 configuration, this F drive would appear where it says it does (at which point Drive G would no longer appear where it should).
So my guess is that something happened to the BIOS settings after I created the second partitions (32kb cluster Drive F) but before I created the third partition (64kb cluster Drive G). This also explains the fairly large unused sector gap between Drives F and G.
I can't imagine my system (BIOS or OS) having a problem with different-sized cluster partitions on the same HDD. Windows NT 4.0 can read and edit 64kb clusters (and even read - but not edit - Fat 32 drives if you have an add-on).
So either there was a BIOS hiccup after I created Drive F but before I created Drive G. Or my system can't handle partitions on the same HDD that have different cluster sizes.
As for Drive F being marked "EXTENDED", I seem to recall I may have created it that way when formatting this partition.
I have no reason to believe any corruption has occurred on any of these partitions. My system's paging file appears on Drive F (partition 2) and given how often it expands and shrinks, and considering how many zip files I have on that partition, I think corruption would be painfully obvious. A casual check of random zip files shows no sign of corruption.
At some point in the next week or two I'll have to back everything on this HDD onto another HDD, this time creating only 32kb clusters. Then reformat the troubled HDD to see if the problem happens again.
Posted 25 October 2015 - 06:30 AM
If you've been able to establish that the partition starts at the correct physical sector (logical block) but that does not correspond to the CHS location, that would seem to confirm a translation error. Clusters shouldn't be a factor there since they are a file system characteristic, not a hardware one.
I still think it might be best to establish beyond doubt the official CHS parameters for the drive and when you embark on re-doing it, enter those values manually.
Posted 25 October 2015 - 03:07 PM
Update: possible jumper discrepancy if the manual contains incorrect information.
The Master Boot Record sides discrepancy I mentioned in my previous post - 240/256 - is in the ratio of 15/16 the same ratio of the sides discrepancy in the Bios set-up. 240*63=15120 sectors per cylinder versus 256*63=16128 sectors per cylinder.
Partion 2 (Drive F) begins in the middle of a cylinder. I don't have the numbers here with me, but it's something like cylinder 280, side 53, sector 1 instead of cylinder 273, side 0, sector 1. FWIW, the official starting point takes me to an earlier, quite wrong physical sector.
WINNT has no problem reading these drives/partitions.
Indeed my original assumption that if the sides were adjusted from 239 (240) to 255 (256) Drive F's starting point would now be in the correct cylinders/sides/sector position. The large gap between partitions two and three (drives F and G) exists so that Drive G can begin at the start of a new cylinder.
So clearly this proves that the corruption happened after I created the second partition (Drive F) but before I created the third partition (Drive G).
An online manual for the slave HDD confirms the 16383/16/63 configuration - I'll verify it with the HDD label the next time I open my computer.
This manual also raises a can of worms courtesy of the jumper settings. The manual gives the user the option of a 15 logical head default. However, the jumper settings I'm using clearly should make this HDD a 16 head slave ... at least according to the manual. After creating the 2nd partition (Drive F) but before creating the 3rd partition (Drive G) I changed jumper settings, moved the HDD off the 2nd IDE cable, re-hooked my DVD burner and put this slave HDD on the outer ribbon slot on my Master HDD IDE cable. I know, I know, the Master is supposed to go on the outer. But BIOS, WINNT, DOS have no problem knowing which drive is Master and which is Slave.
Will getting the IDE cable slots wrong reverse the jumper settings?
Edited by computerdownhouse, 25 October 2015 - 03:09 PM.
Posted 27 October 2015 - 01:36 PM
Update: My latest research indicates that this is a DOS-related bug: it can't read any disk that has 256 heads - it reads 256 as "zero". Either BIOS or the HDD itself steps in and changes the cylinder/head settings.
This website has interesting information about large drives and disk translation algorithms:
In short, the rechs algorithm for a maximum-sized 7.9gb disk forces the number of physical heads to 15 to avoid using the number 256 which DOS would conflate with 0. I have an "induced" 8.4gb drive which uses some kind of lba algorithm - head count on the first two partitions is 255 and the sectors per track is 63 and is therefore consistent with LBA logical geometry. However...
8.4 My 4GB+ drive has problems in MSDOS 6.22 or below.
Some BIOSes assign a drive of over 8192 cylinders a translated geometry with 256 heads. MSDOS 6.22 and below fail when they try to access the last head. If your BIOS allows a user definable drive type, use a geometry with 15 heads and 16/15 times the original number of cylinders, rounded down. Thanks to universal translation you can always do this. Remember to write down the geometry somewhere so that you can reproduce it if necessary! If no user definable drive type is possible, there's little you can do about this except upgrade to Win95.
According to wikipedia, "A bug in all versions of Microsoft DOS/IBM PC DOS up to and including 7.10 will cause these operating systems to crash on boot when encountering volumes with 256 heads. Therefore, all compatible BIOSes will use mappings with up to 255 heads (00h..FEh) only, including in virtual 255×63 geometries."
Comments: I can manually change the cylinders/heads to 16383/16 in the BIOS set-up. It remains this way no matter how many times I boot into windows. Clicking on autodrive will retain this setting. Curiously, the boot process only acknowledges my Master drive. I suspect that this may have something to do with the 256/240 heads discrepancy in my Slave drive's MBR. Despite this, BIOS set-up recognizes the Slave Drive and my OS has no problems reading from and writing to the disk. No corruption ensues.
However, the system hangs during the boot process if I try booting from Dos 6.21/6.22. I enter BIOS set-up click autodrive and it chooses the 15 head 17475 cylinder setting. Then Dos boots.
So it seems likely that either BIOS or the HDD (or both) know that the ancient OS can't read the 16 head setting and so automatically change the disk configuration. It also seems likely that this hiccup occurred after I created the first two partitions but before the third partition. This explains why Windows NT 4.0 formatted the third partition with only 240 heads.
Still don't know if it's BIOS or DOS that keeps deleting "Fat 16" from the first two slave partitions' boot sectors after I boot in DOS.
Moral of the story? Don't use obsolete hardware/software.
Edited by computerdownhouse, 27 October 2015 - 01:54 PM.
Posted 06 November 2015 - 04:32 PM
I tested several more large hdds on my antiquated system and they all bounce to the 15 head 17475 cylinder setting when booting from DOS. So clearly this is a standard BIOS and/or HDD action.
0 members, 0 guests, 0 anonymous users