由于外部不可避免的情况*，我需要在目录中有超过32k的目录（但据我所知，小于64k）。 我正在达到ext3的极限。 我认为原来的服务器正在运行ReiserFS。 备份存储在S3中。
我的解决scheme是升级到ext4，根据维基百科：
在ext3中一个目录最多可以有32,000个子目录。 在ext4这个限制增加到64,000。
我的问题是：将安装fs作为ext4自动增加此限制？ 我将不得不运行一些命令来启用新function吗？ 我必须重新创build目录吗？
*恢复备份将信息转换成我们编写的新的更好的系统
简短的回答：是的。 从ext3转换到ext4确实解决了这个问题。
漫长的回答：
以下是我如何解决这个问题：
我有一个5TB的RAIDarrays，在分区上有大约4TB的数据。 所以我：
将以下内容从ext3转换为ext4：
tune2fs -O extents,uninit_bg,dir_index /dev/DEV 其中/ dev / DEV对我来说就像/ dev / sdb1
然后我跑了：
e2fsck -fDC0 /dev/DEV
这花了约8小时运行4TB的数据。
然后我修改/ etc / fstab来告诉它挂载分区为ext4。
然后我跑了
mount /big
/ big是我的分区的名字。 它完美的工作。
所以要回答你的问题，是转换到ext4实际上解决了这个问题。
阅读这些之前，你做这个转换： http : //www.debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4
不，更改fstypes并将其安装为ext4不会使inode的数量变大。 这是在文件系统创build的时候决定的，不能在ext * fs中随时更改。
而且，通过卸载和安装ext4并不是一个非常干净和推荐的方法。 ext3是基于块的，ext4是基于扩展的，即使你将ext3挂载为ext4，它仍然是基于块的。 所以，你不会得到ext4的主要好处。
如果您有testing系统，则可以尝试执行转换并观察dumpe2fs输出。
对源代码进行了快速检查。 它是硬编码的。
/* * Maximal count of links to a file */ #define EXT3_LINK_MAX 32000 /*
从include/linux/ext3_fs.h
对原始问题的替代解决scheme可能是：每隔几分钟停止一次恢复过程，并检查是否有例如10000个子目录。 如果是这样，创build一个新的目录（甚至可能不在这个目录中），移动10000个目录，并创build符号链接。 这样你就可以得到预期的结构而不会达到FS限制。
我没有全部的答案，但是这个和我运行的实验一样接近。 一旦您在文件系统上运行此命令：
tune2fs -O extents,uninit_bg,dir_index /dev/DEV
你可以在目录中创build更多的32k目录。
我不知道的部分（我现在找不到）是否将其挂载为ext4，但启用了较less的function让我们创build超过32k个目录。