理解索引节点的概念
我指的是链接 关于索引节点的概念
我对以下部分感到困惑：
- 12 个直接块指针
- 1 个单间接块指针
- 1 个双间接块指针
- 1 个三重间接块指针
现在该图显示每个指针都是 32/64 位。
- [查询]：为什么以及如何推断这些值？我的意思是为什么专门只有 32 位或 64 位指针？
该图显示，每个指针 {4 字节/8 字节} 一个数据块 {8 KB}
- [查询]：这实际上是如何实现的？即 8*1024 字节 / 8 字节 = 1024 字节？ 8KB 块的 8 字节指针背后的逻辑是什么？
I am referring to the link about concepts of Inodes
I am confused on parts:
- 12 direct block pointers
- 1 single indirect block pointer
- 1 double indirect block pointer
- 1 triple indirect block pointer
Now the diagram says that each pointer is 32/64 bits.
- [Query]: Why and how are these values inferred? I mean why specifically have only 32 or 64 bit pointers?
The diagram says, One data block {8 KB} for each pointer {4 bytes/8 bytes}
- [Query]: How does this actually work out? i.e. 8*1024 bytes / 8 bytes = 1024 bytes? What is the logic behind having a 8 bytes pointer for 8KB block?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最大文件大小的计算示例
Sample calculation of maximum file size
所指的指针是磁盘块地址 - 每个指针都包含识别磁盘上的块所需的信息。由于每个磁盘块至少为 512 字节（有时为 4096 或 8192 字节），因此使用 32 位地址，磁盘最多可以寻址 512 * 4 * 10243 = 2 TiB（Tebibytes - 更常称为太字节）假设 1/2 KiB 块；随着块大小的增加，大小也会相应变大（因此 8 KiB 块大小为 32 TiB）。对于较大磁盘的寻址方案，您必须转向更大的块大小或更大的磁盘地址 - 因此 48 位或 64 位地址可能是可行的。
因此，回答 Q1 时，32 位是很多东西的常见大小。通常，当 32 位不再足够大时，下一个合理的大小是 64 位。
：
对于 8 KiB 数据块，如果文件为 96 KiB 或更小，则它在磁盘上使用 12 个或更少的块，并且所有这些块地址都直接存储在 inode 本身中。
当文件变大时，磁盘驱动程序会分配一个间接块，并将其记录在 inode 中。当驱动程序需要获取一个块时，它会将间接块读入内存，然后从间接块中找到所需块的地址。因此，它需要（名义上）两次读取才能获取数据，尽管间接往往会缓存在内存中。
通过 8 KiB 块大小和 4 字节磁盘地址，您可以在单个间接块中容纳 2048 个磁盘地址。因此，对于 96 KiB + 1 字节到 16 MiB 左右的文件，只有一个间接块。
如果文件变得更大，则驱动程序会分配一个双间接块。双间接块中的每个指针都指向单个间接块。因此，您可以再拥有 2048 个间接块，每个间接块可以有效地指向 16 MiB，从而导致可存储高达 32 GiB（大约）的文件。
如果文件变得更大，则驱动程序会分配一个三重间接块。三重间接块中的 2048 个指针中的每一个都指向一个双块。因此，在具有 32 位地址的 32 位寻址方案下，可以寻址高达约 64 TiB 的文件。除非在此之前您已经用完磁盘地址（最大 32 TiB，因为 32 位地址对应 8 KiB 块）。
因此，inode 结构可以处理大于 32 位磁盘地址可以处理的文件。
我将把它作为练习留给读者，以了解 64 位磁盘地址的情况如何变化。
The pointers referred to are disk block addresses - each pointer contains the information necessary to identify a block on disk. Since each disk block is at least 512 bytes (sometimes 4096 or 8192 bytes), using 32-bit addresses the disk can address up to 512 * 4 * 10243 = 2 TiB (Tebibytes - more commonly called Terabytes) assuming 1/2 KiB blocks; correspondingly larger sizes as the block size grows (so 32 TiB at 8 KiB block size). For an addressing scheme for larger disks, you would have to move to larger block sizes or larger disk addresses - hence 48-bit or 64-bit addresses might be plausible.
So, to answer Q1, 32-bits is a common size for lots of things. Very often, when 32 bits are no longer big enough, the next sensible size is 64 bits.
Answering Q2:
With 8 KiB data blocks, if the file is 96 KiB or smaller, then it uses 12 blocks or less on disk, and all those block addresses are stored directly in the inode itself.
When the file grows bigger, the disk driver allocates a single indirect block, and records that in the inode. When the driver needs to get a block, it reads the indirect block into memory, and then finds the address for the block it needs from the indirect block. Thus, it requires (nominally) two reads to get to the data, though of course the indirect tends to be cached in memory.
With an 8 KiB block size and 4-byte disk addresses, you can fit 2048 disk addresses in the single indirect block. So, for files from 96 KiB + 1 byte to 16 MiB or so, there is only a single indirect block.
If a file grows still bigger, then the driver allocates a double indirect block. Each pointer in the double indirect block points to a single indirect block. So, you can have 2048 more indirect blocks, each of which can effectively point at 16 MiB, leading to files of up to 32 GiB (approx) being storable.
If a file grows still larger, then the driver allocates a triple indirect block. Each of the 2048 pointers in a triple indirect block points to a double block. So, under the 32-bit addressing scheme with 32-bit addresses, files up to about 64 TiB could be addressed. Except that you've run out of disk addresses before that (32 TiB maximum because of the 32-bit addresses to 8 KiB blocks).
So, the inode structure can handle files bigger than 32-bit disk addresses can handle.
I'll leave it as an exercise for the reader to see how things change with 64-bit disk addresses.
在给出答案之前，您应该了解文件系统的工作原理：
每当用户或程序通过名称引用文件时，操作系统都会使用该名称来查找相应的 inode，从而使系统能够获取所需的信息关于该文件以执行进一步的操作。也就是说，类 Unix 操作系统中的文件名仅仅是带有索引节点号的表中的一个条目，而不是直接与文件关联（与其他操作系统（例如 Microsoft Windows 系统）相反）。索引节点号及其相应的索引节点保存在索引节点表中，索引节点表存储在文件系统中的战略位置，包括其开头附近。
第一个问题的答案是位空间涵盖了全部 32 位或 64 位。只是它使 2^32 足够大，可以定义所有这些变量。此外，为了进一步使用，它必须知道操作位的大小。在您的示例中，它们只是以这种方式定义。
其次，每个指针（大小取决于您的磁盘容量）引用一个数据块（磁盘上8KB，磁盘有块），但请记住unix文件系统具有分层结构。一个表指向许多其他表，最后最后一个表指向该数据块。
我建议您阅读这本书，对于理解 Unix 文件系统。
Before giving the answers, you should understand how file system works:
Whenever a user or a program refers to a file by name, the operating system uses that name to look up the corresponding inode, which then enables the system to obtain the information it needs about the file to perform further operations. That is, a file name in a Unix-like operating system is merely an entry in a table with inode numbers, rather than being associated directly with a file (in contrast to other operating systems such as the Microsoft Windows systems). The inode numbers and their corresponding inodes are held in inode tables, which are stored in strategic locations in a filesystem, including near its beginning.
Answer for the first question is that bit space covers the total 32 or 64 bit. simply it makes 2^32 and it is large enough define the all these variables.Also, for further uses it has to know the size of the bits for operations.In your example they just defined in that way.
Second each pointer (size depends on your disk capacity) reference a data block(8KB on disk, disk has blocks) but keep in mind that unix file system has an hierarchical structure. A table that points many other tables and finally the last table point to the data block.
i offer you to go over this book, very useful to understand the Unix file system.