在分区通过ecryptfs进行encryption的服务器上出现以下错误。 [3440851.003561] Valid eCryptfs headers not found in file header region or xattr region, inode 22545087 [3440830.026081] Valid eCryptfs headers not found in file header region or xattr region, inode 22553905 卸载下面的encryption分区和ext4分区后，我执行了一个fsck ，给了我以下结果： fsck from util-linux 2.20.1 e2fsck 1.42.9 (4-Feb-2014) /dev/sda3: clean, 65092/72302592 files, 54219978/289200384 blocks 我有点不知道发生了什么事。 我们在几个实例上使用相同的设置，我们只在其中一个上观察。 解决scheme可能是更改底层磁盘！ 但是我想了解发生了什么事情，以便最终发现并防止这种事件。
我的需要总结 我们把大量的文件放在文件系统中，以备以后分析。 我们无法控制我们将要拥有的文件数量，而这一个盒子需要访问所有文件。 不可改变的限制 我无法更改inode限制。 这是ext4，这是默认的40亿美元 总会有很多文件。 问题不在于如何减less文件数量; 这是如何规避4Bn的inode限制。 我无法使用networking存储。 这个盒子住在一个数据中心，由于现有数据吞吐量惊人的数量，networking存储不是一个选项。 我的想法 我可以在我们放置这些文件的位置将文件挂载为回送设备。 Pro：简单实施 Con：复杂性的另一层，但非常薄。 XFS。 没有inode限制。 亲：这显然只是消除了这个问题。 Con：不确定在生产系统中进行这种改变有多大的灵活性。 我的问题 为了规避这个严峻的限制，还有哪些其他的方面呢？ 我提到的方法还有其他的好处/缺点吗？
根据btrfs我有一个损坏的文件 BTRFS info (device sdb1): csum failed ino 367 off 310013952 csum 1601485211 expected csum 3692975992 我假设ino 367意味着inode 367，所以我可以使用find并尝试恢复文件。 然而find /path -inum 367找不到任何东西。 任何人都知道如何find损坏的文件？
我正在调查一个非常奇怪的io问题。 我启用了vm.block_dump，并以这种forms看到消息的分配： 进程（29177）：在0:14变脏inode 42254471（文件名） 什么变脏的inode是什么意思？
我有一些在SLES 10（现在已经很久以前的EOL）上已经运行了十年以上的系统。 我们正在迁移到CentOS 6 64位。 我把所有的东西都完成了，但是最后的数据同步了，瞧，惊讶，我用完了磁盘空间，除了inode表，不是原始容量。 ReiserFS（在SLES框中使用）并没有强制实施一个限制 – 事实上，我甚至不知道有多less个inode正在使用，因为它不但没有执行，甚至也没有跟踪/报告它们。 我可以用一行就可以得到这个数字，没问题。 我的问题很大程度上围绕着LVM。 这是我的弱点。 我只是真的使用它，自1993年以来主要使用原始设备。 我拥有的是具有逻辑卷组的新机器，其中包含交换分区和作为两个卷的根文件系统。 这是一个巨大的100GB，但它需要有超过6.5mil的inode …我用完了6.4mil。 我完全理解，我需要得到一个全新的ext4文件系统，因为你根本无法增加inode计数。 我在VMWare下工作，这有帮助。 我可以根据需要简单地添加/删除虚拟驱动器。 我想基本上用一个有更好的inode比率的根文件系统replace我们的用途。 我不确定的是如何处理这个的LVM部分，以及实际的“恢复数据而不恢复文件系统[即保存inode表的部分等]本身，我基本上需要得到数据到一个空闲的虚拟驱动器，根据需要重新格式化根分区，然后恢复驱动器，LVM以我的方式进入知识领域，在某种程度上我熟悉了lvcreate，lvchange等等。我可以使用一个正确的描述哪些工具正确地使用来处理整个文件系统（它是一个文件系统，所有驻留在/，所以它包括/ dev等），只要备份和恢复，特别是LVM换出。 如果有助于编写命令等，则假定vg_webserver4c6为逻辑卷组，lv_root和lv_swap为逻辑卷名称。 lv_root是问题的孩子。 任何帮助非常感谢 – 越详细，越好！ 谢谢！
我正在处理文件系统中的一亿个文件（分布在许多子目录中），我需要能够非常快速地列出它们，特别是为了有效地同步它们。 另一方面，我并不需要将文件的实际内容保存在caching中。 我不断地添加和删除文件，但并不经常（类似于每秒十次）。 有没有一种方法可以告诉操作系统（2.6.18-194.el5）在inodecaching上使用24GB可用RAM，而不是文件caching？ 我已经看过/ proc / etc / vm / vfs_cache_pressure，但它似乎不是我正在寻找…
作为对一些Nagios脚本进行全面检查的一部分，我正在为脚本添加参数，以便可以逐个机器地确定阈值。 例如，我们正在指定可用于触发重要和警告警报的磁盘空闲百分比。 其中一个脚本监视/proc/sys/fs/inode-nr – 这有两个值， nr_inodes和nr_free_inodes 。 我对UNIX的内部知识没有太多的了解，所以我不太确定是否可以根据这个值来设置这个文件的阈值。 nr_inodes和nr_free_inodes会build议正在使用的inode的数量可以计算为(nr_inodes – nr_free_inodes) 。 因此，在猜测中，随着使用中的数字接近nr_inodes X％和Y％，脚本应分别触发警告和紧急警报。 这似乎是一种正确的假设吗？ 谢谢 丰富
我想知道是否有一些规则（或公式）可以用来确定ext4分区中文件系统将使用多less磁盘空间。 例如，在100 GB的分区中，我可以使用多less？ 它取决于其他参数，如inode大小等？
我想在我的服务器上pipe理大量的文件（比如说几百万）。 需要将文件保存在两个或三个级别的文件夹中，以使每个文件夹中的文件数量保持较低。 另一方面，有很多文件夹花费inode是不好的。 每个文件夹的最佳文件比率是多less？ 有没有一个理论的方法来确定这个，还是取决于服务器的规格？
我被xfs击中了设备上没有剩余空间 。 根据常见问题解答： http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_receive_No_space_left_on_device_after_xfs_growfs.3F 解决这个问题的唯一方法是移动数据以释放1TB以下的空间。 find最旧的数据（即在第一次增长之前就已经存在了），并将其从文件系统移出（移动，而不是复制）。 那么如果你复制它，数据块将会超过1TB，这将给你留下足够的空间来存放低于1TB的索引节点。 但是，如何识别要移动的数据呢？ 我不能按年龄去，因为第一个10 TB是在同一天使用rsync填写的。 我努力了： xfs_db -r -c "blockget -i 1 -n -v" /dev/md3 但我似乎只获取文件的基本名称，而不是文件的完整path。 而且因为我的很多文件被称为相同（但在不同的目录），那么这是不是很有用。 而且它似乎给了我更多的信息，只是inode 1。 我有一种感觉，我可以使用xfs_db并得到这个告诉我哪些文件在第一个TB中使用块，但我一直无法看到。 （通过使用mount选项inode64文件系统不会给设备上留下空间 ，但如果您以后忘记使用安装选项inode64那么您将再次获得设备上没有剩余空间我想避免安装选项inode64为文件系统可能会被别人挂载到其他系统上，他们会忘记这一点，从而在设备上留下令人惊讶的空间 ）。