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

脚本中的哪个命令将导致下一个“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/* .

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

相关内容