系统中所有内容是以文件（文件夹是特殊的文件）存在的，而文件分为属性（元信息）和内容两部分，磁盘一部分被操作系统虚拟为块用来存储数据，同时也分出一部分虚拟为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 的区别。
读取时，磁头线圈切割磁场线产生感应电流，磁性材料的磁场方向不同，所以产生的感应电流方向也不同。
光盘和硬盘储存原理不一样，直接比较其储存密度和介质的体积之间的关系没有意义，例如硬盘和光盘都可以在更高的工艺水平和技术下大幅提高自己的储存密度。
简单说来，光储是靠光线传播的差异来储存信息，包括反射光的强度，相位变化等，磁储是靠磁体中磁畴（小磁针）的指向来记录信息的。