相关疑难解决方法(0)

文件名存储在文件系统中的什么位置？

它不在 inode 或实际文件内容中，因为我们有两个文件名可以指向同一个 inode 的硬链接。

众所周知，空文本文件的字节数为零：

但是，它们中的每一个都包含metadata，根据我的研究，它存储在inodes 中，并且确实使用 space。

鉴于此，我认为可以通过纯粹创建空文本文件来填充磁盘。这样对吗？如果是这样，我需要在 1GB 的磁盘中填充多少个空文本文件？

为了做一些检查，我运行了，df -i但这显然显示了正在使用的 inode 的百分比（？），而不是它们的重量。

Filesystem             Inodes  IUsed    IFree IUse% Mounted on
udev                   947470    556   946914    1% /dev
tmpfs                  952593    805   951788    1% /run
/dev/sda2            28786688 667980 28118708    3% /
tmpfs                  952593     25   952568    1% /dev/shm
tmpfs                  952593      5   952588    1% /run/lock
tmpfs                  952593     16   952577    1% /sys/fs/cgroup
/dev/sda1                   0      0        0     - /boot/efi
tmpfs                  952593     25   952568    1% /run/user/1000
/home/lucho/.Private 28786688 667980 28118708    3% /home/lucho

我有点不好意思问这个问题，但我想看一个图表，显示以下事情是如何相关的。如果图表还包括在各个层之间进行映射所需的任何转换，那就太好了。

据我了解，我相信它们以下列方式相关，但我不确定我的理解是否 100% 准确。

                           .-----------------.
                           |      inode      |
                           '-----------------'
                                    |
                           .-----------------.
                           |      EXT4       |
                           '-----------------'
                                    |
                         .---------------------.
                         | logical volume (LV) | --- part of LVM
                         '---------------------'
                                    |
                          .-------------------.
                          | volume group (VG) |  --- part of LVM
                          '-------------------'
                                    |
                            .---------------.
                            | /dev/<device> |
                            '---------------'
                                    |
                   .--------------------------------.
                   | Logical Block Addressing (LBA) |
                   '--------------------------------'
                                    |
                           .-----------------.
                           | blocks/sectors  |
                           '-----------------'
                                    |
                                   HDD     
                                _.-----._  
                              .-         -.
                              |-_       _-|
                              |  ~-----~  |
                              |           |
                              `._       _.'
                                 "-----"   

参考

• 查找硬盘驱动器扇区占用文件
• 识别与不可读磁盘扇区关联的文件
• smartmontools 的坏块 …

我知道目录是一个包含行类型为“名称 = 节点编号”的文件。

当我请求像 /home/my_file.txt 这样的路径时，会发生以下步骤：

1. 转到第 2 个 inode（根目录默认 inode）
2. 获取 inode #2 指向的文件。
3. 搜索此文件并找到“home”条目。获取其 inode 编号，例如 135。
4. 获取 inode #135 指向的文件。
5. 搜索此文件并找到“my_file.txt”条目。获取其 inode 编号，例如 245。
6. 获取 inode #245 指向的文件。

问题：如果主目录是另一个文件系统的挂载点，驻留在另一个块设备上，这个过程有何不同？当系统理解时，这个目录是挂载点，它是如何做到的？这些信息存储在哪里 - 在 inode、目录文件或其他地方？

例如，显示 inode 编号的根目录列表的一部分：

ls -d1i /*/

inode # name
656641  /bin/
2       /boot/
530217  /cdrom/
2       /dev/
525313  /etc/
2       /home/
393985  /lib/

在这里，主目录和引导目录是挂载点并驻留在自己的文件系统上。运行我的伪代码算法（上面写的）并停留在第 3 步 - 在这种情况下，home inode 号是 2，它位于另一个文件系统和另一个块设备中。

我想知道将有关文件的信息存储在inode 中而不是直接存储在目录中是否值得额外的开销。可能我高估了开销或忽略了一些重要的事情，但这就是我问的原因。

我看到硬链接需要像“inode”这样的东西，但如果开销真的和我想象的一样大，我想知道是否有任何理由证明它是合理的：

• 使用硬链接进行备份很聪明，但与正常操作的效率相比，备份的效率还不够重要
• 硬链接既没有速度也没有大小损失真的很重要，因为这种优势仅适用于使用硬链接的少数文件，而对所有文件的访问会受到开销
• 为几个同名的二进制文件节省一些空间，例如bunzip2并且bcat可以忽略不计

我并不是说 inodes/hardlinks 不好或没用，但它能否证明额外间接的成本是合理的（缓存肯定有很大帮助，但它不是灵丹妙药）？

可能的重复：
什么是超级块、索引节点、Dentry 和文件？

Unix 文件系统的文档通常包含术语“inode”。那是什么，那是什么？为什么 DOS/Windows 文件系统没有 inode（或者没有）？

我的理解是文件描述符是一个整数，它是内核每个进程映射到open()ed 文件、管道、套接字等对象的关键。

“打开文件/套接字/管道/...”，文件描述符的指涉对象，是否有一个适当的、简短的和特定的名称？

将它们称为“文件”会导致与存储在文件系统中的未打开文件混淆。简单地引用文件描述符并不能充分描述语义（例如，在进程之间复制整数是无用的）。

查阅The Open Group Base Specifications和我自己系统的联机帮助页，我得出这样的结论：文件描述符的所指对象是一个对象，当它具体是一个打开的文件时，它就是一个打开的文件。有比object更具体的术语吗？

相关：什么是超级块、索引节点、Dentry 和文件？

没有一个著名的元数据结构保留实际文件的位置数据。Dentry 将名称映射到 inode，而 inode 存储有关文件的信息——系统如何知道文件的实际数据位在磁盘上的位置？是否有某种 inode 整数到磁盘位置的默认映射？

我试图在非常基本的层面上理解这三个文件系统之间的差异。

• 分布式文件系统：HDFS
• 平行 FS : 光泽
• 传统文件系统：ext4/ext3/NTFS/FAT 等。

我想知道这三个文件系统之间的基本概念差异是什么。我的大部分知识是关于传统文件系统的，即 ext3/4超级块、inode 等。

• 如果基于 MPI 的进程 (np=8) 尝试从文件系统读取文件或写入文件 A，那么文件访问机制在这些上下文中有何不同
• 文件是如何存储在这个环境中的？即文件 A 将被拆分到多个磁盘或文件 A 将在存储上有冗余副本。或者更简单的场景是多个用户打开一个word文档然后保存它，那么在这3个场景中回写/同步有何不同

到目前为止，我已经形成了一些概念：-

• 在本地文件系统中，存储物理安装在服务器/节点上。
• 在并行文件系统中，一个磁盘在多个节点上共享（挂载），并且，
• 在分布式FS中，多个节点有多个本地存储，但它们都通过某种机制同步。

如果我有 A、B 是工作站而 C、D 是磁盘：

1. 如果 C物理安装在 A 上并格式化为 ext4，那么它就是传统的文件系统。
2. 如果 C 物理安装在存储服务器 Z + C 是网络安装（NFS）在 A 和 B 上，那么这就是集群 FS。
3. 如果 C 物理安装在 A 上，网络安装在 B 上，D 物理上安装在 B 上，网络安装在 A 上。那么这就产生了分布式 FS。

尽管有些答案指出元数据和数据位于并行文件系统中的单独服务器上，但在这里我也想了解如何在分布式文件系统中管理元数据？

这是怎么回事，如果你在一个包含各种文件的文件夹中——图片、二进制可执行文件、脚本、甚至目录、zip 文件，几乎所有的东西——当你点击时ls -l，你会得到类似的输出（到表格）所有文件？

这就像文件本身被放置在统一的超级文件中，并附加了元数据，有点像进程的控制块结构。

为什么您期望与 Unix 或 Linux 无关的文件没有问题？是否有一个文件系统预处理器来处理来自 Windows 世界的文件？或者是不需要的跨平台文件？（那会是什么！）

有没有办法可以看到这个隐藏的（？）层？（即使是 HTML（更不用说 Lisp 等）也很难通过阅读来理解。但是当您看到它时，您会立即理解。）

我试图了解什么是 inode。然而，维基百科的这段话让我感到困惑：

使用 inode 文件系统安装新库很简单。一个正在运行的进程可以访问一个库文件，而另一个进程替换该文件，创建一个新的 inode，并且新文件将存在一个全新的映射，以便随后尝试访问该库的尝试获得新版本。此工具消除了重新启动以替换当前映射库的需要。因此，在更新程序时，最佳做法是先删除旧的可执行文件，然后为更新版本创建一个新的 inode，这样任何执行旧版本的进程都可以不受干扰地继续进行。