C 语言约定从 0 开始计算数组索引。为什么 inode 编号从 1 开始而不是 0?
如果保留inode 0 是为了某些特殊用途,那么inode 0 的意义是什么?
C 语言约定从 0 开始计算数组索引。为什么 inode 编号从 1 开始而不是 0?
如果保留inode 0 是为了某些特殊用途,那么inode 0 的意义是什么?
0 用作标记值以指示 null 或没有 inode。类似于 C 中的指针如何为 NULL。没有哨兵,您需要一个额外的位来测试结构中的 inode 是否已设置。
更多信息在这里:
所有块和inode地址都从1开始。磁盘上的第一个块是块1。0用于表示没有块。(稀疏文件可以在其中包含这些)
http://uranus.chrysocome.net/explore2fs/es2fs.htm
例如,在旧文件系统中,目录被表示为文件条目的固定数组,删除文件会导致将该条目的 inode val 设置为 0。在遍历目录时,任何 inode 为 0 的条目都将被忽略。
通常,inode 0 是保留的,因为返回值 0 通常表示错误。Linux 内核中的多个方法——尤其是在所有文件系统共享的 VFS 层中——返回一个 ino_t,例如find_inode_number。
有更多保留的 inode 编号。例如在ext2中:
#define EXT2_BAD_INO 1 /* Bad blocks inode */
#define EXT2_ROOT_INO 2 /* Root inode */
#define EXT2_BOOT_LOADER_INO 5 /* Boot loader inode */
#define EXT2_UNDEL_DIR_INO 6 /* Undelete directory inode */
和ext3有:
#define EXT3_BAD_INO 1 /* Bad blocks inode */
#define EXT3_ROOT_INO 2 /* Root inode */
#define EXT3_BOOT_LOADER_INO 5 /* Boot loader inode */
#define EXT3_UNDEL_DIR_INO 6 /* Undelete directory inode */
#define EXT3_RESIZE_INO 7 /* Reserved group descriptors inode */
#define EXT3_JOURNAL_INO 8 /* Journal inode */
和ext4有:
#define EXT4_BAD_INO 1 /* Bad blocks inode */
#define EXT4_ROOT_INO 2 /* Root inode */
#define EXT4_USR_QUOTA_INO 3 /* User quota inode */
#define EXT4_GRP_QUOTA_INO 4 /* Group quota inode */
#define EXT4_BOOT_LOADER_INO 5 /* Boot loader inode */
#define EXT4_UNDEL_DIR_INO 6 /* Undelete directory inode */
#define EXT4_RESIZE_INO 7 /* Reserved group descriptors inode */
#define EXT4_JOURNAL_INO 8 /* Journal inode */
其他文件系统使用 ino 1 作为根 inode 编号。通常,文件系统可以自由选择其 inode 编号和保留的 ino 值(0 除外)。
OSX 指定 inode 0 表示已删除的文件尚未删除;这可能也用于其他文件系统,因为 OSX 是 BSD 派生的,尽管至少 NetBSD 现在似乎已经删除了这种用法。
有关 getdirentries,请参阅 OSX 手册页http://developer.apple.com/library/ios/#documentation/System/Conceptual/ManPages_iPhoneOS/man2/getdirentries.2.html
当我很久以前编写文件系统时,我使用 inode 0 作为.badblocks
伪文件。
在某些文件系统.badblocks
上,根目录中实际上是作为 root 和模式 0 拥有的常规文件存在的。root 可以打开它,但读取或写入它是未定义的。
有一些古老的传统,inode 从 1 开始,#1 是.badblocks
,#2 是根目录。尽管.badblocks
没有特别好的保证,但许多文件系统会竭尽全力使 root #2。