在8秒内检测16 GB笔式驱动器上的内容更改

Question

我必须检测可播放的媒体（音频，视频和图像）是否已在具有30,000个文件的16GB笔式驱动器上更改，在后续插入的8秒内。 不考虑其他文件，如pdf或纯文本; 这是一个媒体播放器软件。

我试过ls -l和md5但它需要10-11秒。 有没有人曾经解决过这个问题或者你可以建议的任何策略？

内容可以更改的方案是用户可以弹出笔式驱动器，向其添加更多歌曲，然后重新插入相同的笔式驱动器。 如果没有内容更改，那么我可以使用旧数据库，从而节省播放时间。

我不能依赖时间戳，因为在Windows系统上重命名文件不会改变修改时间。

Answer 1

只需检查文件大小而不是md5总和。 这应该更快，资源更少。

Answer 2

我假设您在这里散列ls的输出，以便在重命名，添加，大小更改或时间戳（对于确实很好的系统）上触发哈希更改，因为我猜测散列16GB分割超过30,000个文件需要超过11秒（虽然大多数建议应该以任何方式工作）

您可能最终必须使用较低级别的API编写自己的代码来访问文件列表。 ls被设计成人类可读的而不是速度。 您不需要查询人类可读的权限，用户名，组等，并且您将通过将其传输到md5来生成内存副本。

您可以尝试使用find命令，它看起来更快，并且只能指定文件。 如果没有管道，它仍然不如真正的程序有效。 这个是非递归的（但是ls -l也是如此），如果你想要的不仅仅是名字，你还可以指定自定义格式输出：

find . -maxdepth 1 -type f | md5sum

您也可以尝试使用MD5的替代哈希。 MD5是一种加密哈希，它的设计是为了抵御故意的恶意冲突，但结果却比较慢。

MurmurHash3是最快或更新的xxhash之一 。 但它将取决于数据的硬件和大小（一些散列针对小键（例如散列映射）进行了优化）。

你也可以试一试它。 让一个线程连续读取驱动器中的文件列表，另一个线程尽可能快地读取它们。

如果您希望使用标准shell来执行此操作，但无需编写自己的代码，那将会非常痛苦。

说了这么多，你的主要瓶颈可能就是闪存的速度。 如果您的CPU缺乏等待I / O，那么世界上所有的技巧都无济于事。 我不确定这是一个很好的“挑战”，因为它将取决于驱动器制造商和USB版本（除非已经指定）。 但也许可以做一切可能会刮掉几秒钟并带你进入你的目标。 或者只是获得更快的USB记忆棒。