當前位置:首頁 » 服務存儲 » 硬碟存儲數據設計
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

硬碟存儲數據設計

發布時間: 2022-12-09 13:11:28

硬碟如何實現信息的存儲

一塊小小的硬碟,儲存的信息幾乎可以相當於全世界圖書館的總和,是怎麼做到的?

雖然硬碟在我們生活中已經隨處可見,但他的儲存方法和原理,卻不是每人都了解的。

想像一架飛機以離地面1毫米的高度飛行,每25秒繞地球一圈,還能覆蓋每一寸表面。

再將其縮小成手掌大小,你就會得到和現代硬碟差不多的東西,它所包含的信息比你們當地圖書館還要多。

那麼它是如何在這么小的空間 儲存這么多的信息呢?

多虧了一代又一代工程師,材料科學家,還有量子物理學家們的共同努力,這個擁有不可思議的能量, 無比精確的小工具才能在你手掌中旋轉。

歡迎關注微信公眾號infoVision,更多精彩科普動畫等著你!

⑵ 硬碟是怎麼存儲數據的啊

【硬碟存儲數據方式】硬碟是在硬質碟片(一般是鋁合金,以前 IBM 也嘗試過使用玻璃)上塗敷薄薄的一層鐵磁性材料。硬碟儲存數據的原理和盒式磁帶類似,只不過盒式磁帶上存儲是模擬格式的音樂,而硬碟上存儲的是數字格式的數據。寫入時,磁頭線圈上加電,在周圍產生磁場,磁化其下的磁性材料;電流的方向不同,所以磁場的方向也不同,可以表示 0 和 1 的區別。讀取時,磁頭線圈切割磁場線產生感應電流,磁性材料的磁場方向不同,所以產生的感應電流方向也不同。
不論是什麼計算機文件,歌曲、視頻、圖片、文檔等等,都是以一個二進制的序列存在的,也就是很多個"10010001110011......"這樣的東西,硬碟上的存儲的文件實際上就是存儲著這些0和1的序列。硬碟的磁頭能夠按照指令讀取相應位置的信號,並且能夠改變指定位置的磁場方向,這就是數據的讀和寫。

⑶ 硬碟是怎麼來存儲數據的

硬碟不是直接存儲我們現在人看到的數據,計算機中,通過2進制,將數據轉化為可以用2進製表示的數字數據,再對應機器的高電平低電平等可以用兩種機器物理狀態的狀態。

硬碟儲存數據的原理和盒式磁帶類似,只不過盒式磁帶上存儲是模擬格式的音樂,而硬碟上存儲的是數字格式的數據。寫入時,磁頭線圈上加電,在周圍產生磁場,磁化其下的磁性材料;電流的方向不同,所以磁場的方向也不同,可以表示 0 和 1 的區別。

讀取時,磁頭線圈切割磁場線產生感應電流,磁性材料的磁場方向不同,所以產生的感應電流方向也不同。

(3)硬碟存儲數據設計擴展閱讀

硬碟使用注意事項:

1、在工作時不能突然關機。

硬碟當硬碟開始工作時,一般都處於高速旋轉之中,如果我們中途突然關閉電源,可能會導致磁頭與碟片猛烈磨擦而損壞硬碟,因此要避免突然關機。關機時一定要注意麵板上的硬碟指示燈是否還在閃爍,只有在其指示燈停止閃爍、硬碟讀寫結束後方可關閉計算機的電源開關。

2、防止灰塵進入。

灰塵對硬碟的損害是非常大的,這是因為在灰塵嚴重的環境下,硬碟很容易吸引空氣中的灰塵顆粒,使其長期積累在硬碟的內部電路元器件上,會影響電子元器件的熱量散發,使得電路元器件的溫度上升,產生漏電或燒壞元件。

3、要防止溫度過高或過低。

溫度對硬碟的壽命也是有影響的。硬碟工作時會產生一定熱量,使用中存在散熱問題。溫度以20~25℃為宜,過高或過低都會使晶體振盪器的時鍾主頻發生改變。溫度還會造成硬碟電路元器件失靈,磁介質也會因熱脹效應而造成記錄錯誤。

⑷ 2020-12-02 硬碟如何存儲文件

系統中所有內容是以文件(文件夾是特殊的文件)存在的,而文件分為屬性(元信息)和內容兩部分,磁碟一部分被操作系統虛擬為塊用來存儲數據,同時也分出一部分虛擬為Inode用來存儲文件屬性,這樣磁碟就分為塊區和inode區。

扇區:磁碟存儲數據的最小物理單元,每個扇區很小512位元組左右。
讀取數據:OS要想讀取磁碟數據,首先讓磁頭徑向尋道(最慢),然後旋轉磁碟(較快),使磁頭到達目標扇區,開始讀取數據。

磁碟塊:OS日常工作中,一個扇區的512位元組數據很小,不足以支撐絕大部分工作場景,所以需要頻繁讀取單個扇區,而磁碟讀取數據速度相對CPU處理太慢了,所以讀磁碟時一次就多拿出幾個扇區(臨近的,無需耗費額外時間)的數據,於是在OS層面邏輯虛擬出磁碟塊(簇)的概念,一個磁碟塊一般對應8個連續扇區(也可4、16個等,由OS決定),這樣OS層面就使用磁碟塊作為最小數據存儲單元。
這樣的好處當然是更高效,缺點則是會?

inode:用於存儲文件的元信息(除名稱外的所有屬性,名稱存在文件夾的內容中)
Inode number is also known as index number. An inode is a unique number assigned to files and directories while it is created. The inode number will be unique to entire filesystem.

Disk inodes contain the following information:

Owner identifier
Type of file (regular, directory, character or block device)
Access permissions
Times and dates
· file creation time

· last file access time

· last inode modification time

Number of links to the file
Array of pointers to data blocks on disk
File size (in bytes, sometimes also in blocks)

文件:
上文提及文件屬性存在磁碟inode區的inode(每個都有編號)內,而內容存儲在塊區的塊中。

文件夾:
作為特殊文件,其組織文件及目錄,屬性也是存在inode內,而存儲的內容是一個包含多個{ 文件名:對應inode Id} 的列表,內容亦存在塊區的塊中。

這樣在OS中查看一個文件(比如/etc/fstab)的內容,大概是:
首先OS獲取到根目錄的inodeId >在inode區中讀取到其屬性(某項是內容所在塊)>在塊區讀取到根目錄內容>在內容中找到名為/etc對應發inodeId>/etc在inode區的屬性>讀取到塊中/etc的內容(包含/etc/fstab對應inodeId)>/etc/fstab Inode Id > 在inode區讀取到/etc/fstab屬性 >/etc/fstab塊。

可能有誤,望指點。

Within each file system, the mapping from names to blocks is handled through a structure called an i-node. There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures. A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links); they're just multiple directory entries that happen to point to the same i-node.

refer: https://unix.stackexchange.com/questions/432655/why-does-using-indirect-pointers-in-inodes-not-incur-the-same-amount-of-space

less:by direct list blocks in node?.
large :by two-level indirect block
larger : multi-level indirect block.

The original hierarchy of the inodes levels works roughly like this:

You can store one or a few block numbers directly in the inode. This means you use a few bytes more for the inode, but for small files, you don't have to allocate a complete block, which is mostly empty.

The next level is one indirection: You allocate a block to store the block pointers. Only the address of this indirect block is stored in the inode. This doesn't use somehow "less space", and most filesystems, even early ones, worked like that (have a pointer near the inode/filename which points to a block, which stores the block numbers of the file).

But what do you do when the space in this block runs out? You have to allocate another block, but where do you store the reference to this block? You could just add those references to the inode, but to store largers files, the inode would get large. And you want small inodes, so as many as possible inodes can fit into a single block (less disk access to read more inodes).

So you use a two-level indirect block: You just add one pointer to the inode, then you have a whole block to store pointers to indirect blocks, and the indirect blocks store the block address of the file itself.

And so on, you can add higher-level indirect blocks, or stop at some stage, until you reach the maximal size of a file possible with the structure you want.

So the point is not "use up less space in total", but "use a scheme that uses blocks efficiently for the expected distribution a files wrt. to size, i.e. many small files, some larger files, and very few huge files".

Page tables on the other hand work very differently.

Edit

To answer the questions in the comment:

Data blocks are of fixed sizes (originally 512 bytes, IIRC), which is a multiple of the block size of the underlying harddisks. So data block size can't "decrease".

As I tried to describe above, the whole point of having the inodes not use up too much space is to make inode access faster (or, alternatively, make caching inodes use up less memory - back then when the unix file system with inodes was invented, computers had a lot less memory than today). It's not about somehow saving space in total. As you say yourself, everything has to be stored somewhere, and if it doesn't use up space at location X, it will use up space at location Y.

Just adding a variable number of block pointers to the inode is not practical, because the inode must take up a fixed amount of space - you want to use the inode number to calculate the block address and the offset inside the block where the inode information is stored. You can't do that if every inode has a different size. So there must be some form of indirection.

Page tables work differently because hardware implements them differently - that's just how it is. The hierarchy has a fixed depth, always the same (though sometimes configurable. And while reading a block from disk is slow, that doesn't matter for page tables. So the design issues are completely different.

http://www.cems.uwe.ac.uk/~irjohnso/coursenotes/lrc/internals/filestore/fs3.htm

Assuming, for the purposes of illustration, that each disk data block is 1024 bytes in size, then these ten data block pointers will allow files to be created that are up to 10 Kb in size. As you can see, for the large majority of files it should be possible to access the data with nothing more than a direct lookup required to find the data block that contains any particular data byte.

With this scheme, once a file has grown to 10 Kb, there are only three block pointers in the inode left to use, whatever the eventual size of the file. Obviously, some new arrangement must be found so that the three remaining block pointers will suffice for any realistic file size, while at the same time not degrading the data access time too much.

This goal is achieved by using the idea of indirect block pointers. Specifically, when an 11th data block needs to be allocated to the file, the 11th inode block pointer is used, but instead of pointing to the block which will contain the data, the 11th pointer is a single indirect pointer which points to a data block filled with a list of direct block pointers. In our example, if we assume that a data block number is a 32-bit value, then a list of 256 of them will fit into the single indirect block. This list will point directly to the data blocks for the next 256 Kb of our file. This means that with 11 block pointers in the inode, files of up to 266 Kb (10 + 256) can be created. True, it takes a little longer to access the data beyond the first 10 Kb in the file, but it takes only one extra disk block read to find the position on the disk of the required data.

For files bigger than 266 Kb the double indirect (12th) inode block pointer is used. This is the same idea as the previous inode pointer except that the double indirect pointer points to a list of pointers in a data block, each of which is itself a single indirect block pointer which points to a list of 256 direct block pointers. This means that the 12th inode block pointer gives access to the next 65536 Kb (256x256) of data in our file.

By now, you should be able to spot the pattern and see that when the file grows bigger than 64 Mb (actually 65802 Kb), the inode's 13th data block pointer will be used, but this time as a triple indirect pointer, which will give access to a staggering 16 Gb (256x256x256 Kb) of extra file space. A single file bigger than 16Gb sounds huge. However, even though the calculation we have just done suggests that this file size is possible with the inode layout as given, in fact there are other factors which limit the maximum size of a file to a smaller value than this. For example, the size of a file, in bytes, is stored separately in its inode in a field of type unsigned long. This is a 32-bit number which limits the size of a file to 4 Gb, so that 13 data block pointers in an inode really are enough.

10.4. How a file gets looked up
Now we can look at the file system from the top down. When you open a file (such as, say, /home/esr/WWW/ldp/fundamentals.xml) here is what happens:

Your kernel starts at the root of your Unix file system (in the root partition). It looks for a directory there called 『home』. Usually 『home』 is a mount point to a large user partition elsewhere, so it will go there. In the top-level directory structure of that user partition, it will look for a entry called 『esr』 and extract an i-node number. It will go to that i-node, notice that its associated file data blocks are a directory structure, and look up 『WWW』. Extracting that i-node, it will go to the corresponding subdirectory and look up 『ldp』. That will take it to yet another directory i-node. Opening that one, it will find an i-node number for 『fundamentals.xml』. That i-node is not a directory, but instead holds the list of disk blocks associated with the file.

The surface area of your disk, where it stores data, is divided up something like a dartboard — into circular tracks which are then pie-sliced into sectors. Because tracks near the outer edge have more area than those close to the spindle at the center of the disk, the outer tracks have more sector slices in them than the inner ones. Each sector (or disk block ) has the same size, which under modern Unixes is generally 1 binary K (1024 8-bit bytes). Each disk block has a unique address or disk block number .

Unix divides the disk into disk partitions . Each partition is a continuous span of blocks that's used separately from any other partition, either as a file system or as swap space. The original reasons for partitions had to do with crash recovery in a world of much slower and more error-prone disks; the boundaries between them rece the fraction of your disk likely to become inaccessible or corrupted by a random bad spot on the disk. Nowadays, it's more important that partitions can be declared read-only (preventing an intruder from modifying critical system files) or shared over a network through various means we won't discuss here. The lowest-numbered partition on a disk is often treated specially, as a boot partition where you can put a kernel to be booted.

Each partition is either swap space (used to implement virtual memory ) or a file system used to hold files. Swap-space partitions are just treated as a linear sequence of blocks. File systems, on the other hand, need a way to map file names to sequences of disk blocks. Because files grow, shrink, and change over time, a file's data blocks will not be a linear sequence but may be scattered all over its partition (from wherever the operating system can find a free block when it needs one). This scattering effect is called fragmentation .

Within each file system, the mapping from names to blocks is handled through a structure called an i-node . There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures . A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links ); they're just multiple directory entries that happen to point to the same i-node.

In the simplest case, your entire Unix file system lives in just one disk partition. While you'll see this arrangement on some small personal Unix systems, it's unusual. More typical is for it to be spread across several disk partitions, possibly on different physical disks. So, for example, your system may have one small partition where the kernel lives, a slightly larger one where OS utilities live, and a much bigger one where user home directories live.

The only partition you'll have access to immediately after system boot is your root partition , which is (almost always) the one you booted from. It holds the root directory of the file system, the top node from which everything else hangs.

The other partitions in the system have to be attached to this root in order for your entire, multiple-partition file system to be accessible. About midway through the boot process, your Unix will make these non-root partitions accessible. It will mount each one onto a directory on the root partition.

For example, if you have a Unix directory called <tt class="filename">/usr</tt>, it is probably a mount point to a partition that contains many programs installed with your Unix but not required ring initial boot.

⑸ 長期存儲數據用什麼類型的硬碟

長期儲存數據,最注重的就是安全性……
這里的「安全性」,指的是存儲數據的硬碟必須長期保持完好,不能出故障。
普通電腦硬碟,是按照8×7設計的……
也就是說,這樣的硬碟是按照每天工作8小時、每周工作7天的使用負荷程度設計的。
這樣的硬碟,顯然不能滿足重要數據長期存儲的需求。
有一種企業級硬碟,是按照24×7設計的……
具體來說,這樣的硬碟是按照每天工作24小時,每周工作7天的使用負荷程度設計的,基本上白天晚上不停地連軸轉了……其故障率更低,安全性更高,更適合於長期存儲數據。
但是,再好的硬碟也不可能百分百無故障。
所以,靠單塊硬碟存儲數據,安全性還是不高的……可以用多塊硬碟備份數據,這樣一塊硬碟有問題,其他硬碟上還有數據,可以提升安全性。
如果是比較高級的應用,就需要磁碟陣列等技術的加持了……

採用磁碟陣列技術,多塊硬碟實現互相備份,這樣可以大幅度提升數據存儲安全性,最適合於重要數據的長期存儲……這在伺服器領域,已經被廣泛採用了。
aqui te amo。

⑹ 我想問下硬碟為什麼能存儲數據把信息存儲到上面的時候是以什麼原理進行的刪除它的時候又是什麼原理呢

電腦只認識0和1。但是解碼方式有很多種,比如在文字方面00000000代表「中」
00000001代表「國」所以00000000 00000001就被電腦翻譯成「中國」
硬碟的物理結構
1、磁頭
硬碟內部結構磁頭是硬碟中最昂貴的部件,也是硬碟技術中最重要和最關鍵的一環。傳統的磁頭是讀寫合一的電磁感應式磁頭,但是,硬碟的讀、寫卻是兩種截然不同的操作,為此,這種二合一磁頭在設計時必須要同時兼顧到讀/寫兩種特性,從而造成了硬碟設計上的局限。而MR磁頭(Magnetoresistive heads),即磁阻磁頭,採用的是分離式的磁頭結構:寫入磁頭仍採用傳統的磁感應磁頭(MR磁頭不能進行寫操作),讀取磁頭則採用新型的MR磁頭,即所謂的感應寫、磁阻讀。這樣,在設計時就可以針對兩者的不同特性分別進行優化,以得到最好的讀/寫性能。另外,MR磁頭是通過阻值變化而不是電流變化去感應信號幅度,因而對信號變化相當敏感,讀取數據的准確性也相應提高。而且由於讀取的信號幅度與磁軌寬度無關,故磁軌可以做得很窄,從而提高了碟片密度,達到200MB/英寸2,而使用傳統的磁頭只能達到20MB/英寸2,這也是MR磁頭被廣泛應用的最主要原因。目前,MR磁頭已得到廣泛應用,而採用多層結構和磁阻效應更好的材料製作的GMR磁頭(Giant Magnetoresistive heads)也逐漸普及。
2、磁軌
當磁碟旋轉時,磁頭若保持在一個位置上,則每個磁頭都會在磁碟表面劃出一個圓形軌跡,這些圓形軌跡就叫做磁軌。這些磁軌用肉眼是根本看不到的,因為它們僅是盤面上以特殊方式磁化了的一些磁化區,磁碟上的信息便是沿著這樣的軌道存放的。相鄰磁軌之間並不是緊挨著的,這是因為磁化單元相隔太近時磁性會相互產生影響,同時也為磁頭的讀寫帶來困難。一張1.44MB的3.5英寸軟盤,一面有80個磁軌,而硬碟上的磁軌密度則遠遠大於此值,通常一面有成千上萬個磁軌。
3、扇區
磁碟上的每個磁軌被等分為若干個弧段,這些弧段便是磁碟的扇區,每個扇區可以存放512個位元組的信息,磁碟驅動器在向磁碟讀取和寫入數據時,要以扇區為單位。1.44MB3.5英寸的軟盤,每個磁軌分為18個扇區。
4、柱面
硬碟通常由重疊的一組碟片構成,每個盤面都被劃分為數目相等的磁軌,並從外緣的「0」開始編號,具有相同編號的磁軌形成一個圓柱,稱之為磁碟的柱面。磁碟的柱面數與一個盤面上的磁軌數是相等的。由於每個盤面都有自己的磁頭,因此,盤面數等於總的磁頭數。所謂硬碟的CHS,即Cylinder(柱面)、Head(磁頭)、Sector(扇區),只要知道了硬碟的CHS的數目,即可確定硬碟的容量,硬碟的容量=柱面數*磁頭數*扇區數*512B。
[編輯本段]硬碟的邏輯結構
1. 硬碟參數釋疑
到目前為止, 人們常說的硬碟參數還是古老的 CHS(Cylinder/Head/Sector)參數。那麼為什麼要使用這些參數,它們的意義是什麼?它們的取值范圍是什麼?
很久以前, 硬碟的容量還非常小的時候,人們採用與軟盤類似的結構生產硬碟。也就是硬碟碟片的每一條磁軌都具有相同的扇區數。由此產生了所謂的3D參數 (Disk Geometry). 既磁頭數(Heads),柱面數(Cylinders),扇區數(Sectors),以及相應的定址方式。
其中:
磁頭數(Heads)表示硬碟總共有幾個磁頭,也就是有幾面碟片, 最大為 255 (用 8 個二進制位存儲);
柱面數(Cylinders) 表示硬碟每一面碟片上有幾條磁軌,最大為 1023(用 10 個二進制位存儲);
扇區數(Sectors) 表示每一條磁軌上有幾個扇區, 最大為 63(用 6個二進制位存儲);
每個扇區一般是 512個位元組, 理論上講這不是必須的,但好像沒有取別的值的。
所以磁碟最大容量為:
255 * 1023 * 63 * 512 / 1048576 = 7.837 GB ( 1M =1048576 Bytes )或硬碟廠商常用的單位:
255 * 1023 * 63 * 512 / 1000000 = 8.414 GB ( 1M =1000000 Bytes )
在 CHS 定址方式中,磁頭,柱面,扇區的取值范圍分別為 0到 Heads - 1。0 到 Cylinders - 1。 1 到 Sectors (注意是從 1 開始)。
2. 基本 Int 13H 調用簡介
BIOS Int 13H 調用是 BIOS提供的磁碟基本輸入輸出中斷調用,它可以完成磁碟(包括硬碟和軟盤)的復位,讀寫,校驗,定位,診,格式化等功能。它使用的就是 CHS 定址方式, 因此最大識能訪問 8 GB 左右的硬碟 (本文中如不作特殊說明,均以 1M = 1048576 位元組為單位)。
3. 現代硬碟結構簡介
在老式硬碟中,由於每個磁軌的扇區數相等,所以外道的記錄密度要遠低於內道, 因此會浪費很多磁碟空間 (與軟盤一樣)。為了解決這一問題,進一步提高硬碟容量,人們改用等密度結構生產硬碟。也就是說,外圈磁軌的扇區比內圈磁軌多,採用這種結構後,硬碟不再具有實際的3D參數,定址方式也改為線性定址,即以扇區為單位進行定址。
為了與使用3D定址的老軟體兼容 (如使用BIOSInt13H介面的軟體), 在硬碟控制器內部安裝了一個地址翻譯器,由它負責將老式3D參數翻譯成新的線性參數。這也是為什麼現在硬碟的3D參數可以有多種選擇的原因(不同的工作模式,對應不同的3D參數, 如 LBA,LARGE,NORMAL)。
4. 擴展 Int 13H 簡介
雖然現代硬碟都已經採用了線性定址,但是由於基本 Int13H 的制約,使用 BIOS Int 13H 介面的程序, 如 DOS 等還只能訪問 8 G以內的硬碟空間。為了打破這一限制, Microsoft 等幾家公司制定了擴展 Int 13H 標准(Extended Int13H),採用線性定址方式存取硬碟, 所以突破了 8 G的限制,而且還加入了對可拆卸介質 (如活動硬碟) 的支持。

⑺ 硬碟是怎麼來存儲數據的

硬碟儲存數據的原理和盒式磁帶類似,只不過盒式磁帶上存儲是模擬格式的音樂,而硬碟上存儲的是數字格式的數據。寫入時,磁頭線圈上加電,在周圍產生磁場,磁化其下的磁性材料;電流的方向不同,所以磁場的方向也不同,可以表示 0 和 1 的區別。

讀取時,磁頭線圈切割磁場線產生感應電流,磁性材料的磁場方向不同,所以產生的感應電流方向也不同。


光碟和硬碟儲存原理不一樣,直接比較其儲存密度和介質的體積之間的關系沒有意義,例如硬碟和光碟都可以在更高的工藝水平和技術下大幅提高自己的儲存密度。



簡單說來,光儲是靠光線傳播的差異來儲存信息,包括反射光的強度,相位變化等,磁儲是靠磁體中磁疇(小磁針)的指向來記錄信息的。

⑻ 硬碟是如何存儲數據的

硬碟數據存儲原理

硬碟是一種採用磁介質的數據存儲設備,數據存儲在密封於潔凈的硬碟驅動器內腔的若干個磁碟片上。這些碟片一般是在以鋁為主要成分的片基表面塗上磁性介質所形成,在磁碟片的每一面上,以轉動軸為軸心、以一定的磁密度為間隔的若干個同心圓就被劃分成磁軌(track),每個磁軌又被劃分為若干個扇區(sector),數據就按扇區存放在硬碟上。在每一面上都相應地有一個讀寫磁頭(head),所以不同磁頭的所有相同位置的磁軌就構成了所謂的柱面(cylinder)。傳統的硬碟讀寫都是以柱面、磁頭、扇區為定址方式的(CHS定址)。硬碟在上電後保持高速旋轉(5400轉/min以上),位於磁頭臂上的磁頭懸浮在磁碟表面,可以通過步進電機在不同柱面之間移動,對不同的柱面進行讀寫。所以在上電期間如果硬碟受到劇烈振盪,磁碟表面就容易被劃傷,磁頭也容易損壞,這都將給盤上存儲的數據帶來災難性的後果。

硬碟的第一個扇區(0道0頭1扇區)被保留為主引導扇區。在主引導區內主要有兩項內容:主引導記錄和硬碟分區表。主引導記錄是一段程序代碼,其作用主要是對硬碟上安裝的操作系統進行引導;硬碟分區表則存儲了硬碟的分區信息。計算機啟動時將讀取該扇區的數據,並對其合法性進行判斷(扇區最後兩個位元組是否為0x55AA或0xAA55 ),如合法則跳轉執行該扇區的第一條指令。所以硬碟的主引導區常常成為病毒攻擊的對象,從而被篡改甚至被破壞。可引導標志:0x80為可引導分區類型標志;0表示未知;1為FAT12;4為FAT16;5為擴展分區等等。

硬碟信息與硬碟數據恢復

在計算機的CMOS中也存儲了硬碟的信息,主要有硬碟類型、容量、柱面數、磁頭數、每道扇區數、定址方式等內容,對硬碟參數加以說明,以便計算機正確訪問硬碟。當CMOS因故掉電或發生錯誤時,硬碟設置可能會丟失或錯誤,硬碟訪問也就無法正確進行。這種情況我們就必須重新設置硬碟參數,如果事先已記下硬碟參數或者有某些防病毒軟體事先備份的CMOS信息,只需手工恢復即可;否則也可使用BIOS設置(setup)中的「自動檢測硬碟類型」(HD type auto detection)的功能,一般也能得到正確的結果。
硬碟故障大體上可以分為軟故障和硬故障兩大類,具體有硬碟操作系統被損壞、硬碟主引導區被破壞、 FAT表表被破壞、CMOS硬碟參數不正確、硬碟控制器與硬碟驅動器未能正常連接、硬碟驅動器或硬碟控制器硬體故障、主板故障等情況。比如:
開機自檢過程中,屏幕提示「Hard disk drive failure」或類似信息,則可以判斷為硬碟驅動器或硬碟控制器(提示「Hard drive controller failure」)硬體故障。
開機自檢過程中,屏幕提示「Hard disk not present」或類似信息,則可能是CMOS硬碟參數設置錯誤或硬碟控制器與硬碟驅動器連接不正確。
開機自檢過程中,屏幕提示「Missing operating system」、「Non OS」 、「Non system disk or disk error,replace disk and press a key to reboot」等類似信息,則可能是硬碟主引導區分區表被破壞、操作系統未正確安裝或者CMOS硬碟參數設置錯誤等。
開機用軟盤啟動後無法進入C盤,可能是分區表被破壞,硬碟數據恢復是可以的。