☰

脚本中的哪个命令将导致下一个“ls”立即列出文件？

tag-icon • tag-icon ls performance
脚本中的哪个命令将导致下一个“ls”立即列出文件？

概括

我可以在 bash 脚本中运行什么命令，使ls终端的下一个命令立即列出目录中的文件，而不必等待 10 秒？

请参阅“详细信息”末尾的问题 1 和问题 2。

详细信息

我的目录中有 700 个视频文件 (mp4)，大小从 100 MB 到 1 GB 不等。平均文件大小为 200 MB。

当我在启动后第一次列出它们时（在终端中使用 ls 或使用 pcmanfm），需要 10 秒才能列出文件。此后，当我再次列出它们（使用 ls 或在 pcmanfm 中）时，这些文件几乎立即列出。

因此，为了尝试绕过这个初始等待时间，我在启动后在脚本中运行了以下命令：

ls /path/to/vid-directory

...这样，当我用 ls 或 pcmanfm 列出目录时，文件会立即列出。

但奇怪的是，跑步

ls /path/to/vid-directory

SCRIPT 中的 不会导致 NEXT ls 或 pcmanfm 立即列出文件（它们在 10 秒后列出）。同样奇怪的是，当初始脚本运行时，文件几乎立即列出。

因此，在终端运行 ls 似乎会将文件名存储在 RAM 缓存中，而在脚本中运行 ls 则不会*。

问题一：为什么会发生后者*？

问题2：我应该在脚本中运行哪些命令才能使下一个 ls 或 pcmanfm 立即列出文件？

PS：在进行测试时，我通过运行来确保 RAM 最初是空的

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

答案1

ls终端和ls脚本中唯一可能的区别是，您使用别名ls来传递一个选项，该选项不仅需要读取文件名列表，还需要读取文件的属性。选项大概是--color.读取文件名列表只需要从目录本身读取，而读取文件的属性则需要访问每个文件的索引节点（通过lstat系统调用）。因此，当您运行ls该脚本时，只有文件名最终会出现在缓存中，而不是其属性。第一次ls在终端中运行或使用 GUI 文件管理器时，需要加载属性。

ls将与终端上使用的相同选项传递到脚本中。

10 秒只列出 700 个文件是异常缓慢的。文件的大小无关紧要。典型的现代系统只有在处理数万或数十万个文件（如果不是更多）时才会开始明显变慢。

答案2

重启后运行即可查明问题所在：

strace -tt -o ls.strace ls /path/to/directory

的输出ls可以加速，ls -U但是，当然，这确实会改变输出。

700 个文件并不是一个大数字。通过重写所有目录条目可以实现一些加速：

mkdir /tmpdir/on/the/same/filesystem
mv * /tmpdir/on/the/same/filesystem
mv /tmpdir/on/the/same/filesystem/* .

但最有效的解决方案可能是在启动时在后台自动读取该目录。

相关内容