我正在使用f3自定义 Bash 脚本来大量测试 USB 闪存。
我遇到的一个常见问题是，一些有故障的驱动器会使所有健康驱动器的 IO 饿死，从而有效地拖延测试过程。
例如 - 当留下 50 个 USB 驱动器进行测试时，我经常在一小时后发现 48 个什么都不做，而 2 个在闪烁 LED。删除这两个驱动器突然恢复所有其他驱动器测试。
有时会出现更复杂的情况，其中 24 个驱动器停止运行，而其余驱动器似乎工作正常。除了一些驱动器在 20 分钟后没有任何进展。你把它们拔掉，剩下的就会恢复生机，测试继续进行。
但是 - 我还发现停止测试故障驱动器足以使其余驱动器恢复正常。
我正在寻找一种方法来找出哪些驱动器导致其他驱动器出现此文件操作阻塞，以便我可以在我的脚本中自动停止它们。
我一直在观察atop, iostat,htop并dmesg试图找到一个区分因素，但我看不到任何东西。我发现有所谓的usbmon内核调试接口，虽然它太底层了，我真的不知道如何使用它。原始 USB 数据包没有告诉我任何信息。
我可以使用任何其他工具来判断哪些驱动器运行异常吗？
我使用f3write和f3read程序来测试驱动器。该f3write程序创建 1GB 的文件，f3read然后程序读取这些文件以识别过程中发生的任何数据损坏。
此外 - 这很奇怪，但是当存在行为不当的驱动器时，其余“健康”驱动器将完成对当前文件的工作。假设 - 写入或读取 1GB 大小的文件 - 但在移除异常驱动器之前不会创建新文件。这就像在存在“IO hog”驱动器的情况下无法打开新文件一样。
我能做些什么来区分它们？
