系統中所有內容是以文件（文件夾是特殊的文件）存在的，而文件分為屬性（元信息）和內容兩部分，磁碟一部分被操作系統虛擬為塊用來存儲數據，同時也分出一部分虛擬為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.
⑵ 電腦硬碟是干什麼用的
硬碟是用於保存電腦各種文件數據的存儲器。是由包含多個碟片的碟片組加上硬碟驅動器，固定密封在一個專用的盒內。
硬碟的精密度高、存儲容量大、存取速度快。一台電腦可以配一個硬碟，也可以配兩個或多個硬碟。硬碟按尺寸分有3.5英寸、2.5英寸等；按介面分有IDE、SCSI、USB等。家用電腦幾乎都使用3.5英寸的IDE介面硬碟。
電腦硬碟的工作原理
硬碟存儲數據是根據電、磁轉換原理實現的。硬碟由一個或幾個表面鍍有磁性物質的金屬或玻璃等物質碟片以及碟片兩面所安裝的磁頭和相應的控制電路組成，其中碟片和磁頭密封在無塵的金屬殼中。
硬碟工作時，碟片以設計轉速高速旋轉，設置在碟片表面的磁頭則在電路控制下徑向移動到指定位置然後將數據存儲或讀取出來。
寫數據：系統向硬碟寫入數據時，磁頭中「寫數據」電流產生磁場使碟片表面磁性物質狀態發生改變，並在寫電流磁場消失後仍能保持，這樣數據就存儲下來了；
讀數據：系統從硬碟中讀數據時，磁頭經過碟片指定區域，碟片表面磁場使磁頭產生感應電流或線圈阻抗產生變化，經相關電路處理後還原成數據。
⑶ 硬碟存儲器由哪些部分組成它是怎樣工作的
品牌型號：華為MateBook D15系統：Windows 11
硬碟存儲器是由磁碟、磁碟驅動器（或稱磁碟機）和磁碟控制器組成。硬碟存儲器是利用磁記錄技術在塗有磁記錄介質的旋轉圓盤上進行數據存儲的輔助存儲器。具有存儲容量大、數據傳輸率高、存儲數據可長期保存等特點。在計算機系統中，常用於存放操作系統、程序和數據，是主存儲器的擴充。
硬碟存儲器是一種應用廣泛的直接存取存儲器。其容量較主存儲器大千百倍，在各種規模的計算機系統中，常用作存放操作系統、程序和數據，是對主存儲器的擴充。磁碟存儲器存入的數據可長期保存，與其他輔助存儲器比較，磁碟存儲器具有較大的存儲容量和較快的數據傳輸速率。典型的磁碟驅動器包括碟片主軸旋轉機構與驅動電機、頭臂與頭臂支架、頭臂驅動電機、凈化盤腔與空氣凈化機構、寫入讀出電路、伺服定位電路和控制邏輯電路等。
⑷ 硬碟存儲器的作用是什麼
硬碟存儲器主要由硬磁碟、硬碟驅動器和硬碟控制器等三部分組成。驅動器和控制器部分與軟盤存儲器相似。這里只介紹一下硬磁碟。
硬磁碟又稱硬碟(Harddisk)，它是在金屬基片上塗一層磁性材料製成的。目前微機上都採用IBM公司的溫徹斯特技術的硬碟，簡稱溫盤。
微機一般使用5英寸或3英寸的硬碟，並且通常將幾個碟片以驅動器軸為軸線組裝在一起，稱為盤組。每個碟片都有一個磁頭。每個盤面上的磁軌都是同心圓，所有盤面上的同心圓就組成許多圓柱面。因此在硬碟中不稱磁軌而稱柱面，數據的存儲地址由柱面號、磁頭號和扇區號確定。硬碟的存儲容量通常為幾十兆至幾百兆位元組，目前已有1GB、4GB的硬碟。
硬碟的盤組與驅動器組裝在一個固定的密封容器中，能夠防塵並調節溫濕度。硬碟驅動器的磁頭不像軟盤驅動器那樣直接與盤面接觸，而是利用硬碟高速旋轉(比軟盤轉速高許多)產生的「氣墊」，懸浮在距盤面0.2μ的距離，因此不易劃傷盤面，磁頭損耗也大大降低。
⑸ NAS網路存儲器怎麼用
1、NAS設備主要的用途是提供一個文件數據存放的空間。這個空間可以共享給不同的主機。主機可以像訪問本地硬碟一樣訪問NAS存儲空間。
2、從網上下載資料的動作是主機（比如你的辦公電腦）來做，下載的資料可以直接存放到NAS中。
3、不同操作系統主機訪問NAS的方式有一定區別，通常來說：
1）Windows主機通常通過CIFS協議訪問，可以通過在「我的電腦」上點右鍵，「映射網路驅動器」的方式，將NAS的空間作為一個網路硬碟來訪問。
2）Linux或Unix主機通常通過NFS協議訪問，可以使用mount命令將NAS空間掛載成一個本地目錄進行訪問。
3）具體的配置方法各廠家設備有一定區別，請參考設備的使用說明書，或咨詢廠家。
⑹ 硬碟是怎麼來存儲數據的
硬碟儲存數據的原理和盒式磁帶類似，只不過盒式磁帶上存儲是模擬格式的音樂，而硬碟上存儲的是數字格式的數據。寫入時，磁頭線圈上加電，在周圍產生磁場，磁化其下的磁性材料；電流的方向不同，所以磁場的方向也不同，可以表示 0 和 1 的區別。
讀取時，磁頭線圈切割磁場線產生感應電流，磁性材料的磁場方向不同，所以產生的感應電流方向也不同。
光碟和硬碟儲存原理不一樣，直接比較其儲存密度和介質的體積之間的關系沒有意義，例如硬碟和光碟都可以在更高的工藝水平和技術下大幅提高自己的儲存密度。
簡單說來，光儲是靠光線傳播的差異來儲存信息，包括反射光的強度，相位變化等，磁儲是靠磁體中磁疇（小磁針）的指向來記錄信息的。