我正在尝试快速备份大型GNU / Linux文件系统上的ACL。 扩展权限并不是真的有必要。
我在一个小分区上运行4个小基准，只是估计经过的时间（秒）和生成的文件大小（兆字节）。
getfacl -R -p /backup/dir > out_file ：58.715s（36MB） find /backup/dir -printf "%m %u:%g %p \n" > out_file ：54.053s（27MB） find /backup/dir -printf "%m %p \n" > out_file ： 0.763s （26MB） ls -laR /backup/dir > out_file ： 4.865s （20MB） 因此，如果需要用户：组， ls是最好的解决scheme。
理想情况下， out_file应该如下所示：
755 user:group /full/path/to/dir 744 user:group /full/path/to/file ...
但据我所知，从ls获得文件的完整path需要额外的命令，这将减缓进程。 我们正在谈论非常大的文件系统。
没有一个比ls更好（更快/更高效）的工具来处理这个问题吗？
为什么在检索用户时find速度变得如此剧烈：组信息与ls相比？
另外， ls还可以处理文件名上的转义特殊字符（使用-b选项）。
解决了:(谢谢@shodanshok）第一次sync后：
getfacl -n -R -p /backup/dir > out_file ：19.561s（36MB） 但第二次运行相同的命令：
getfacl -n -R -p /backup/dir > out_file ：2.496s（36MB） 根据我的经验， getfacl可以被用户名parsing进程绑定CPU。 尝试添加-n开关，例如发出getfacl -n -R -p /backup/dir > out_file
在基准testing期间，要特别注意inode / dentrycaching，因为它很容易使您的计时testing歪曲。 在每个基准testing之前，发出以下命令以清空两个高速caching： sync; echo 3 > /proc/sys/vm/drop_caches sync; echo 3 > /proc/sys/vm/drop_caches