ext2转储/恢复问题

我正在用maildir存储运行一个邮件服务器。这意味着，相当多的文件被创build，我刚用完inode。 AFAIK没有神奇的命令来增加ext＃文件系统上的inode数量（或者我错了吗？），所以我必须备份和恢复整个文件系统。但是我怎么做？我试图创build另一个分区，并做：

dump -f - -0 /vservers/mail | restore rf - -u -v

虽然这似乎起作用，但比我愿意等待的时间要长得多（在我停止该过程之前，它已经设法在两个小时内创build500个空目录; strace显示恢复过程中调用了大量无用的lseeks）。有没有其他方法来复制完整的文件系统（包括套接字，设备文件，所有者，权限，acls等）？附加信息：源fs是ext3，目标是ext4，文件系统在lvm上，我想移动的fs是vfs的根fs。

我的另一个复制文件系统的build议如下。请记住，最近我遇到这个问题是使用find + xargs + rm来清理一个野生无用的垃圾邮件的maildir，所以你应该在一个小时左右后才能看到这些信息。

 cd root_of_source ; find . -print0 | tar -c --null -T - -f - | tar -sxf - -C root_of_target

这个结构的function是

以原始顺序检索文件列表
- 这就是为什么我使用查找，而不是焦油的默认…我不知道，焦油的默认是坏的，我只知道，发现是好的，
将该列表传递给tar null终止（以便正确处理任何特殊字符）。
以tar格式输出，解压缩目标目录中的结果（不对input（-s）进行重新sorting）。

不pipe你使用什么方法：

如果这些数据在相同的物理磁盘上开始和结束，那么与正常操作（在从源文件读取到写入目标文件之间进行大量的search操作）相比，您的性能自然会吸引很多LOT。
如果你有一些CPU可用，一点压缩不应该伤害，并可能有助于在tar命令之间添加一个'gzip -c -1'阶段，并且在第二个焦点上添加一个-z。

你有没有考虑尝试使用unionfs将现有的文件系统与新的文件系统联合起来，写入新的文件系统？

我自己从来没有使用过UnionFS，但是我听说它听起来像可以让你上线并开始将数据写入磁盘，而不必通过联合现有的文件系统重新创build文件系统，只需要一个新的文件系统作为可写文件系统。有可能是性能命中或其他问题，这使得这是一个没有去，但如果你只是寻找的想法，有一些时间，而转储正在运行，你可以研究这一个可行的一套命令。

作为参考，在一台相当老旧的机器上，需要35分钟才能使用dump | restore来复制一个fs 使用7.8 GB的空间dump | restore fs有420,774个inode。

相比之下，使用tar | tar需要61分钟 tar | tar和64分钟使用cp -ax 。

几个月前，我发布了一个补丁来加快dump速度，但在0.4b44发布之后，还没有另外发布。你可以在邮件列表中find补丁。使用此补丁程序自行构build0.4b44可能会产生显着差异。对我来说，它将时间从35分钟减less到只有25分钟。对邮件列表的反馈会有帮助。