☰

背景

tag-icon • tag-icon io ntfs lsof
背景

背景

我在跑音乐大脑皮卡德更新通过 USB 连接并使用 autofs 挂载的 500GB NTFS 磁盘 (Transcend StoreJet) 上的 ~11M ogg 文件。通过扩展坞进行连接。我不能确定我总是正确卸载它...

我担心的是手术时间太长；我预计整个文件夹会在几分钟内处理完毕，但可能已经花了几个小时了。当我开火时iotop(1)，它报告 ~ 25K/s 磁盘写入，其中 ~99% 用于 picard 进程。 （Picard 并未完全挂起，GUI 会在几分钟内刷新/响应一次）。

为了希望看到一些进展，我不断检查 lsof；整个输出如下所示：

$ lsof /mnt/greeno-ntfs
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
picard  2885 amahdal  mem    REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   14u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   16u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg

但我无法真正理解所有的观察结果——我只能做出一些假设。所以我想我会在这里问。

问题

  • 文件有3个FD正常吗？一个“内存”和两个“常规”？

    我尝试创建一个简单的脚本来打开和更新一个文件（中间休眠需要很长时间），但不，只有一个常规 FD ( 5u)，所以显然正常打开不会像这样。

    假设：这是 Picard（或其库）故意解释的处理潜在长文件 I/O 的（可能是通用的）技术的结果。如果是这样，有人可以解释一下吗？ （例如，为什么是 2+1？）

  • 正如我所注意到的，SIZE/OFFSET 列实际上是缩小 随着时间的推移。

    假设：这对应于 Picard 实际上寻找内部文件并更新，对吗？

随机假设 - 此时，它们中的任何一个作为可能的原因是否有意义？

  • Picard 有 bug（更新/收缩效率极低），

  • 磁盘出现故障（它是5岁以上...),

  • 文件系统安装错误（谁知道如何最佳地安装 ntfs），

  • 文件系统因取消/对接而损坏（无法检查，因为我没有 chkdsk）...

那么接下来怎么办？接下来我可以看到什么来了解正在发生的事情？

答案1

除了皮卡德有问题之外，你的猜测很容易测试。如果文件确实只有 11 MB 大，只需将其复制到 /dev/shm (RAM) 或本机文件系统来测试它。

我当然希望 NTFS 速度慢得多并且使用更多的 CPU，但通常不会将分钟更改为小时。避免使用 ntfs 应该是首先要测试的事情。

lsof 输出可能非常奇怪......有时甚至“lsof -p $pid”与“lsof /path”都有不同的输出，即使第二个仅列出那个 pid。所以我不会试图弄清楚这是否“正常”。

如果您想了解文件的查找和写入，您应该使用 strace，而不是 lsof。

相关内容