标签: inode

我想知道是否有一些规则（或公式）可以用来确定文件系统在 ext4 分区中将使用多少磁盘空间。例如，在 100 GB 的分区中，我实际可以使用多少？它是否取决于其他参数，如 inode 大小等？

在 Linux 上（可能是文件系统块大小的函数），当我创建一个目录stat时，它返回 4096 的大小。我可以在这个目录中创建文件，在一定程度上，不会增加感知的大小目录（由 报告stat）。

在某些时候，当目录填满许多文件时，目录大小会膨胀（我不是在谈论目录的内容，我在谈论代表目录本身所消耗的块）。如果文件被删除，目录大小保持不变。

这是一个快速示例：

[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400

然后触摸一堆文件：

[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096 …

我在使用 Apache2 的 Debian 网络服务器上的 PHP 会话mod_php似乎随机失败，说没有空间来编写它们：

sudo tail -60 /var/log/apache2/error.log
[Fri Jan 30 15:55:35 2015] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  session_start() [<a href='function.session-start'>function.session-start</a>]: open(/tmp/sess_555555555555555555, O_RDWR) failed: No space left on device (28) in /path/to-first-session-use/core/bootstrap.php on line 18

当我尝试：

ls /tmp

它只是永远挂起，所以这很糟糕。

但是当我检查可用空间并检查 inode 使用是否合理时......

$ df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             150G  121G   22G  85% /
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
udev                   10M   16K   10M   1% /dev
tmpfs                 2.0G  4.0K  2.0G   1% …

df -i
Filesystem-----Inodes-----Iused-----IFree-----IUse-----Mounted on
dev/sda2-------732960-----727804-----5156-----100%---- /

只有这两个具有最高的 inode，其余的都太低了。可以做些什么来释放inode？

Proc 10937 inode

Sys 22504 inode

apt-get -f install 说没有空间了

df -i 输出图像

apt-get -f 安装输出错误图像

inodes 搜索输出图像 -

var 日志只有 26Mb（在 var 目录中最高）

经过一些谷歌研究，我发现 inode 的使用可能与目录/文件的数量有关。

• 我猜有一个限制（因此决定了 inode 使用百分比）。这个限制是由什么决定的？
• 如果 Inode 使用率达到 100% 会发生什么？

我正在处理文件系统中的数亿个文件（分布在许多子目录中），我需要能够非常快速地列出它们，特别是为了有效地 rsync 它们。

另一方面，我真的不需要将文件的实际内容保存在缓存中。

我不断地添加和删除文件，但不是那么频繁（大约每秒十次）。

有什么方法可以告诉操作系统 (2.6.18-194.el5) 在 inode 缓存上比在文件缓存上更多地使用 24GB 可用 RAM？我已经看过 /proc/etc/vm/vfs_cache_pressure 但它似乎并不是我正在寻找的......

我们的一台服务器最近遇到了一些文件系统损坏，我们的根文件系统自动重新挂载为只读。我采取的恢复步骤是：

1. 尝试remount > mount -n -o remount /失败
2. 重新启动了服务器
3. 提示执行手动操作fsck，有 5 个孤立的 inode 需要修复。

执行这些步骤后，我能够获得访问权限并且文件系统再次可写。不幸的是，我没有任何内容丰富的日志，因为没有写过，否则我会包含这些日志。

建议的一个原因是我们的数据库太忙而无法将数据正确写入磁盘，这导致了问题，高级别缓存内存表明可能是这种情况。但是我不确定这一点，因为虽然缓存很高，但我们根本没有使用交换（free下面的输出）。

$ free -m
             total       used       free     shared    buffers     cached
Mem:          2041       1879        162          0         62       1599
-/+ buffers/cache:        216       1825
Swap:          471          0        471

故障发生后有什么方法可以诊断故障吗？MySQL 看起来像一个可能的候选者吗？

如果没有，如果再次发生这种情况，我将来应该采取什么措施？

有没有与Linux中的函数inode相同的命令。任何信息都会有所帮助。

我们正在构建一个可能会生成非常大的 XFS 卷的产品，我正在尝试发现在给定架构的情况下我们可能遇到的扩展瓶颈。

当我们操作文件时，它们被放置在 XFS 卷上的目录中。由于我们处理的文件数量，文件数量肯定在数千万，并且在发布后不久可能会达到数亿。我们知道这一点是因为我们当前的产品是这样运行的，所以我们有理由期待我们的下一个产品也有类似的表现。

因此，正确的早期工程是有序的。

本周的文件基于以下粗略布局：

$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file

这给出了看起来有点像的目录：

0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file

分块 md5sum 的原因是为了避免“一个目录中的大堆文件/目录”问题。由于 md5sum 分块，这意味着 1 个文件会导致创建 8 个目录。这对 inode 的影响非常明显，但我不清楚一旦我们达到规模，这些影响将对 XFS 产生什么影响。

有哪些影响？

顺便说一下，这是使用内核 2.6.32，目前是 CentOS 6.2（如果需要，可以更改）。

在测试中，我使用默认值创建了 xfs 卷，并且没有使用任何挂载选项。这是为了尽早解决问题。noatime很简单，因为我们不需要它。总体 XFS 调整是我需要解决的另一个问题，但现在我担心我们现在设计的元数据乘数效应。

我已经知道更好的解决方案是什么，我只是不知道我是否有理由推动改变。

由于 md5sums 的前几个数字非常独特，并且单个子项目很少超过 500 万个文件，在我看来，我们只需要前两个块。这将产生如下布局：

0123456/001/0e15/a644/897219acb4b597f651d69a4d/file

一个完整的第一级和第二级在每个第一级目录中将有 2 ¹⁶个一级目录和 2 ¹⁶个二级目录，卷上总共有 2 ^{32 个}目录。

因此，假设的 500 万个文件子项目将有 2 ¹⁶个一级目录，每个目录中大约有 76 (+/- 2) 个二级目录，每个二级目录中有一个或两个第三级目录。

这种布局的元数据效率更高。我只是不知道是否值得努力改变现在的情况。

我想在我的服务器上管理大量文件（比如数百万）。需要将文件保存在两级或三级文件夹中，以保持每个文件夹中的文件数量较少。另一方面，有很多文件夹来使用inode也不好。

每个文件夹的最佳文件比例是多少？是否有确定这一点的理论方法，还是取决于服务器规格？