『楼 主』:
[讨论] BIOS和分区软件究竟是如何确认硬盘容量的
使用 LLM 解释/回答一下
这是一个困扰于我已久的问题
我就先从当初的504M容量限制的问题说起，当初超过500M的硬盘出现后许多386、486的机器都不认，后来才知道需要有带LBA寻址模式的BIOS支持才行。从那时起，大容量硬盘在BIOS中选LBA似乎是当仁不让的选择。到后来出现了8G容量的限制问题（中间我跳过一些其它不常见的限制），才知道需要有带扩充Int 13h支持的BIOS才行。注意，从这时候起，我的问题来了。我就以AWARD BIOS为例，在4.5版的情况下，我使用它自己的硬盘参数检测功能，当一个超过8G，比如10G、20G、40G的硬盘，BIOS检测后能给出三种参数：NORMAL模式（我认为其实就是传统的CHS模式），LARGE模式和LBA模式。我想我们大多数人都会毫不犹豫的选择LBA模式，然后分区，格式化，装系统，OK！这都没问题。如果我们的目的只是在于机器可以使用，管它内部究竟是怎么回事，那么我们也不必要来这里了，也没必要讨论这个问题了。
我的问题在于：我曾经试过用其它模式，也可以照常使用，那么是否是现在使用什么模式对硬盘来说是无所谓的呢？如果再仔细比较一下就会发现，三种模式下所能识别出的硬盘容量不是完全一样的，但相差不多，只差那么一点点，这不象以前是有“质”的区别。而且有趣的是，过去能够识别最大容量模式的LBA现在所能识别出的反而最小，而过去所能识别容量最小的CHS模式反倒能识别出最大容量，过去处于中庸的LARGE仍然处于中间水平。那么这个硬盘实际的最大可用容量究竟是多少呢？那个在CHS模式下所认出的最大容量究竟是不是可靠的呢？如果在它这个模式下对硬盘的访问会不会有所损伤呢？由于对这些疑问我始终没有找到答案，所以出于保守起见，我以后一直使用的还是LBA模式，在BIOS给出这三种模式下硬盘参数的同时也默认的推荐是这个模式。此外，在一些品牌机的用户手册中也指导用户使用这一模式，我不知道他们这样做确实是有科学依据的，还是人云亦云不经过调查研究图省事写的。
后来BIOS发展到6.0版的时候情况又发生了新的变化，连手工检测硬盘参数的步骤都省去了，只要接上硬盘开机就能自动识别容量和寻址模式（当然，你也可以手工设定其它模式），而且在BIOS中AUTO方式下自动检测出的硬盘模式和参数都是按照CHS方式的，但奇怪的是自检时所显示的硬件信息概要中所报告的硬盘模式几乎都变成了是LBA？！（特殊情况除外，下面我会说明）那么如此看来似乎LBA应该是唯一的、正确的选择了？按理，硬盘的（最大）容量是固定的，BIOS是根据硬盘固件中的信息来识别硬盘容量的，但好象现在的BIOS都过于“聪明”了，它似乎能根据分区表中的信息再来判断一下硬盘的参数、寻址模式和容量，我说的“再来”是因为BIOS似乎有两次检测，第一次是当你进入BIOS设置的时候可以看到它认出缺省的寻址方式（几乎都是CHS，后来实际变成LBA），而当启动时显示硬件配置信息的时候（不一定就是这时候，只是我们是在这时候看到）它还要检测一次，为什么我要这样说呢，如果你的硬盘是全新的、重新分区的，你是看不出两次变化是有什么意义的，可能认为这种变化只是一个假象，只不过是BIOS“例行公事”。但当你的硬盘在另一台机器上是以CHS方式分区的，再装到这台机器上的时候，你就会看到配置信息中显示的也是CHS方式而不是同样会变成LBA模式。另外，我还曾遇到过这样一种情况：一块4G的老硬盘，在BIOS中认出的确实是4G，但在启动时会变成1G，以后在BIOS中就一直变成1G了，我在BIOS中让它重新检测一下还是1G？！在每次清除CMOS让BIOS重新正确认一遍后，每次启动时又会变成1G？！后来我把MBS清零后就再也没有出现这种怪现象。我虽然不清楚BIOS到底是如何识别硬盘的，但通过上述两个例子，我认为现在的BIOS除了通过固件中的信息外，还会通过启动时在引导OS之前会读取硬盘的分区信息来“智能”地确定硬盘的寻址模式和容量。当然，这些只是我的猜测，到底是怎么回事请熟悉BIOS内部结构的朋友来解答一下。
现在再谈谈分区软件对容量的识别问题，传统的FDISK看不出什么，我先不谈。我现在一般是用DM来分区的，并且通常一直使用带/M参数的手动模式下进行操作，我发现DM和FDISK一样，最小的分区单位也是以柱面为单位的，但奇怪的是我常常碰到用DM分过区的硬盘在FDISK的查看下往往还会显示还有1%的未使用空间，（其实也只不过几兆而已，并不是硬盘容量真正的1%）。所以我一直在想会不会是DM是以LBA模式来识别硬盘的，而FDISK是以CHS来识别的，所以要比DM能多认些扇区？其它的分区软件如PM我估计也是以柱面为单位的。UNIX可以以磁道为单位，LINUX不太清楚。
This is a problem that has troubled me for a long time.
I'll start with the issue of the 504M capacity limit. After hard drives with a capacity exceeding 500M appeared, many 386 and 486 machines couldn't recognize them. Later, I learned that support from a BIOS with LBA addressing mode was required. Since then, it seems an inevitable choice to select LBA in the BIOS for large-capacity hard drives. Then there was the problem of the 8G capacity limit (I skipped some other less common limits in between), and I learned that a BIOS with extended Int 13h support was needed. Pay attention, from this time on, my problem came up. I'll take AWARD BIOS as an example. In version 4.5, when I use its own hard drive parameter detection function, when a hard drive exceeding 8G, such as 10G, 20G, 40G, the BIOS detection can give three parameters: NORMAL mode (which I think is actually the traditional CHS mode), LARGE mode, and LBA mode. I think most of us will unhesitatingly choose the LBA mode, then partition, format, install the system, and it's OK! There's no problem with this. If our purpose is just that the machine can be used and we don't care about what's going on inside, then we don't need to come here or discuss this problem.
My problem is: I once tried other modes and could still use it normally. So is it indifferent to the hard drive which mode is used now? If we compare carefully, we will find that the capacities of the hard drive recognized in the three modes are not completely the same, but they are quite close, only a little different. This is not like before when there was a "qualitative" difference. And interestingly, the LBA, which could recognize the largest capacity mode in the past, can now recognize the smallest, while the CHS mode, which could recognize the smallest capacity in the past, can actually recognize the largest capacity, and the LARGE in the middle still remains in the middle level. Then what is the actual maximum available capacity of this hard drive? Is the largest capacity recognized in the CHS mode reliable? Will accessing the hard drive in this mode cause damage to it? Since I have never found an answer to these questions, I have always used the LBA mode out of caution. The BIOS also defaults to recommending this mode while giving the hard drive parameters in these three modes. In addition, in the user manuals of some brand computers, users are also instructed to use this mode. I don't know whether they do this really with scientific basis or just follow suit without investigation and research for convenience.
Later, when the BIOS developed to version 6.0, the situation changed again. Even the step of manually detecting hard drive parameters was omitted. As long as the hard drive is connected and the computer is turned on, it can automatically recognize the capacity and addressing mode (of course, you can also manually set other modes). Moreover, in the AUTO mode in the BIOS, the automatically detected hard drive mode and parameters are all in accordance with the CHS mode, but strangely, the hard drive mode reported in the hardware information summary displayed during self-test almost all becomes LBA?! (Except for special cases, which I will explain below) So it seems that LBA should be the only and correct choice? According to reason, the (maximum) capacity of the hard drive is fixed, and the BIOS recognizes the hard drive capacity according to the information in the hard drive firmware. But it seems that the current BIOS is too "smart". It seems that it can judge the hard drive parameters, addressing mode and capacity according to the partition table information again. I said "again" because the BIOS seems to have two detections. The first time is when you enter the BIOS setup, you can see that it recognizes the default addressing mode (almost all CHS, and later it actually becomes LBA). And when displaying the hardware configuration information during startup (not necessarily at this time, just when we see it), it has to detect again. Why do I say this? If your hard drive is brand new and repartitioned, you can't see the significance of the two changes. You may think that this change is just an illusion, just a "routine" of the BIOS. But when your hard drive was partitioned in CHS mode on another machine and then installed on this machine, you will see that the configuration information also shows the CHS mode instead of also becoming the LBA mode. In addition, I once encountered such a situation: an old 4G hard drive, which was indeed recognized as 4G in the BIOS, but became 1G during startup. Later, it has been 1G in the BIOS all the time. I let it re-detect in the BIOS and it was still 1G?! After clearing the CMOS each time to let the BIOS recognize it correctly again, it became 1G again during each startup?! Later, after I cleared the MBS, this strange phenomenon no longer occurred. Although I don't know how the BIOS recognizes the hard drive exactly, through the above two examples, I think that the current BIOS, in addition to using the information in the firmware, will also "intelligently" determine the addressing mode and capacity of the hard drive by reading the partition information of the hard drive before booting the OS during startup. Of course, these are just my guesses. Please friends who are familiar with the internal structure of the BIOS to explain what's going on.
Now let's talk about the problem of partition software recognizing capacity. The traditional FDISK can't show anything, so I won't talk about it first. I usually use DM to partition now, and usually always operate in the manual mode with the /M parameter. I find that DM and FDISK have the same minimum partition unit in cylinder units, but strangely, I often encounter that the hard drive partitioned by DM often shows 1% unused space under FDISK's view. (Actually, it's only a few megabytes, not really 1% of the hard drive capacity) So I've been wondering whether DM recognizes the hard drive in LBA mode, while FDISK recognizes it in CHS mode, so it can recognize more sectors than DM? I estimate that other partition software such as PM also uses cylinder units. UNIX can use track units, and I'm not sure about LINUX.
|
