我在互联网上搜索,但无法找到解决我的问题的满意答案。我当前遇到的问题是,我正在将数据从 NTFS 分区转换到 ext4 分区。令我惊讶的是,使用 ext4 文件系统我可以在同一硬盘上存储更少的数据。经过一番调查,我发现这可能与 ext4 的 Inode 有关。
me@server:/media$ LANG=C df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 3815552 31480 3784072 1% /media/storage
/dev/sdb1 1905792 1452 1904340 1% /mnt
运行命令时
me@server:~$ sudo find /mnt -type f | wc -l
1431
它告诉我硬盘上有 1431 个文件,每个文件大约 4-8GB。所以基本上我对很少的文件有太多的索引节点。
我的问题是:
- 现在如何更改 Inode 的数量?
- 是否有更好的文件系统来存储文件?
答案1
默认情况下,ext2/ext3/ext4 文件系统为 root 用户保留 5% 的空间。这对于典型配置中的根文件系统来说是有意义的:这意味着如果用户填满磁盘,系统不会停止运行,关键功能仍然可以工作,特别是仍然可以写入日志。在大多数其他场景中这没有意义。
为了避免为 root 用户保留 5%,请在创建文件系统时传递-m 0
to ,或随后使用该选项调用。mkfs
tune2fs
-m 0
不过,如果您的文件系统已满 95%,您应该考虑扩展它。大多数文件系统(包括 NFS 和 ext? 系列)在接近满时都无法有效运行。
答案2
在大多数典型的用例下,大多数使用默认设置创建的文件系统将拥有比它们所需的更多的索引节点。但这实际上是一个相当不错的权衡,考虑到:
- 总而言之,索引节点表并没有真正浪费那么多空间。为了从文件系统中挤出最后几个字节的可用空间而减少 inode 的数量几乎是不值得的。
- 如果减少了 inode 的数量,然后,文件系统耗尽了 inode,但仍然有大量空闲块,那么无法使用所有这些空闲块是非常令人沮丧的,并且您无法轻松解决该问题,因为文件系统创建后就无法更改 inode 的数量。
是否有更好的文件系统来存储文件?
并不真地。ext4
很好。
每个文件系统存储文件的方式都略有不同,因此存储开销也略有不同,但差异应该很小:在最极端的情况下只有几个百分点的差异。
你可以试试xfs
。我过去似乎注意到,在一些文件系统上,我拥有数百万个文件,每个文件大小约为 250KB,xfs
在空间效率方面表现稍好一些。但是 YMMV 因为你的用例是不同的。