有没有办法检查 USB 驱动器是否已停止？

发布于 2024-07-10 22:11:23 字数 1011 浏览 12 评论 0原文

我写了一个脚本来每晚备份我的服务器的硬盘。在脚本结束时，我会同步，等待几分钟，同步，然后发出 sg_start --stop 来停止设备。这个想法是通过在十分钟的增量备份后关闭硬盘来延长设备的使用寿命（台式磁盘可以承受数千个开/关周期，但只能持续运行几百小时）。

这并不总是有效；我经常发现第二天早上驱动器仍在旋转。是否有一个 shell 命令可以用来检查驱动器是否已停止（以便我可以再次发出停止命令 [EDIT2] 或编写一个脚本来在驱动器运行时创建进程列表，以便我可以调试它[/EDIT2] ]）？

[编辑] 我尝试过 sg_inq （按照 sg_start 手册页的建议）但是此命令始终返回 0。

我尝试过 hdparm 但它总是返回“驱动器状态为：未知”对于 USB 驱动器（通过 /dev/sdX 连接），当尝试降低驱动器转速时，我收到“HDIO_DRIVE_CMD(setidle1) 失败：输入/输出错误”。

sdparm 似乎支持在驱动器上设置空闲计时器（请参阅“电源模式条件页”），但 IDLE 选项具有“可更改：n”，并且我还没有找到可以告诉我驱动器电源状态的选项。

[EDIT2] 注意：我可以从控制台使用 sg_start --stop 停止驱动器。这总是有效的；它只是并不总是停留到午夜。服务器位于地下室（那里又漂亮又凉爽），我宁愿有一种方法可以从温暖的客厅检查驱动器是否启动:)如果我有一个命令告诉我驱动器的状态，我可以编写一个脚本来在它旋转时提醒我（每分钟检查一次），然后我可以尝试找出可能导致此问题的原因。

如果这很重要：我正在使用 openSUSE 11.1。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

神爱温柔 2024-07-17 22:11:23

当您说您尝试过 hdparm 时，您并没有说您尝试过什么。我的外壳中有一些 USB 硬盘驱动器，有些命令适用于它，而另一些命令则不然，但我想这一切都取决于传输机制的各个方面。

  hdparm  -S 120  /dev/sda

应该告诉驱动器在大约 10 分钟不活动后自行睡眠。

我猜您已经尝试过这个，但它并不明显，将其写为答案可能会对未来的读者有所帮助。

Nothing accesses the drive but the backup script.

这在理论上很好，但我发现在奇怪的情况下这还不够。有很多进程和任务，即使它们查看驱动器，如果由于某种原因查找不在磁盘缓存中，则可能会发生旋转。

常见的罪魁祸首是 updatedb 等工具扫描所有挂载的文件，以及 fam 或 gamin 执行一些时髦的操作来监视磁盘的更改。

如果有疑问，请在执行脚本之前安装设备并在完成后卸载它，从而增加一层确定性。

查看可能导致唤醒的内容

 lsof +D /mountpoint

在尝试卸载之前，您可能还应该解析其输出，以确保没有任何东西仍在尝试使用它。

您可能还应该执行惰性卸载，

 umount -l /mountpoint

因此如果在执行 lsof| 之间有任何内容访问它， grep 并调用 umount，它仍然会卸载驱动器并阻止读取它。

HAL 和朋友

HAL 和朋友也有可能正在对驱动器进行唤醒，探测连接/删除状态。我真的希望不是这样，但它在某些设备类型上确实如此。这似乎是一个不太可能的原因，但我会考虑任何可能的原因。

尝试一些有趣的东西，例如

lsof /dev/devicehere

和

lsof /dev/devicehere1

，它似乎可以获取将直接或间接访问句柄的所有事物的完整列表。

When you say you've tried hdparm, you haven't said what you have tried. I have some usb hard drives in an enclosure, and some of the commands work for it and others don't, but I guess it all depends on all facets of the transport mechanism.

  hdparm  -S 120  /dev/sda

Should tell the drive to sleep itself after ~10 minutes of inactivity.

I'm guessing you have already tried this, but its not obvious, and writing this as an answer may help a future reader.

Nothing accesses the drive but the backup script.

This is nice in theory, but I have found on odd occasions this is not enough. There are lots of processes and tasks that if they even look at the drive a spin up may occur if the lookup is for some reason out of the disk-cache.

Common culprits are tools like updatedb scanning all mounts for files, and fam or gamin doing funky stuff to monitor disks for changes.

If in doubt, add a layer of certainty by mounting the device before executing the script, and unmounting it when you are done.

Seeing things that could cause a wakeup

 lsof +D /mountpoint

You should probably parse the output of this as well before attempting to unmount to be sure that nothing is still trying to use it.

You should probably also be doing a lazy umount,

 umount -l /mountpoint

so if anything accesses it between you doing lsof| grep and calling umount, it will still unmount the drive and stop things being able to read it.

HAL and friends

Its also possible that HAL and friends are doing wakeups to the drive probing for connect/removal state. I really hope it isn't, but it does that on some device types. It seems an unlikely cause, but I'll consider anything possible.

Try fun stuff like

lsof /dev/devicehere

and

lsof /dev/devicehere1

Which appears to get a comprehensive list of all things that would be accessing the handle either directly or indirectly.

回复收藏 0 原文

绿光 2024-07-17 22:11:23

您还需要检查挂载选项并使用“noatime”作为挂载选项，否则内核仍会定期更新访问时间。所以这也可能是你的问题的原因。

回复收藏 0 原文

空城缀染半城烟沙 2024-07-17 22:11:23

如果hdparm返回此：

 drive state is:  unknown

并且smartctl返回此：

CHECK POWER MODE: incomplete response, ATA output registers missing
CHECK POWER MODE not implemented, ignoring -n option

则无法获取USB驱动器睡眠状态。我尝试了多种创造性的东西，例如USB功耗或监视文件访问，但我没有发现任何东西可以验证驱动器的状态。

唯一的解决方案是将 USB SATA 适配器（或外壳）替换为具有不同 USB 桥接芯片的适配器（或外壳）。那个对我不起作用，使用了 JMicron JMS567 (152d:0578 / 0x152d 0x0578)，这可能是已更新，但我无法测试它，因为更新工具需要ARM CPU。现在我使用两个不同的适配器，它们都使用 Asmedia ASM1051E / ASM1053E / ASM1153 / ASM1153E，并且它们传递所有命令。

您可以按如下方式检查 USB SATA 适配器/外壳的桥接芯片：

lsusb -v | grep -E ': ID |idVendor|idProduct'

返回类似以下内容：

Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
  idVendor           0x174c ASMedia Technology Inc.
  idProduct          0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge

If hdparm returns this:

 drive state is:  unknown

And smartctl returns this:

CHECK POWER MODE: incomplete response, ATA output registers missing
CHECK POWER MODE not implemented, ignoring -n option

Then it is not possible to obtain the usb drive sleep status. I tried multiple creative things like the USB power consumption or monitoring file access, but I found nothing to verify the drive's state.

The only solution is to replace the USB SATA adapter (or enclosure) against one with a different USB bridge chip. The one that did not work for me, used the JMicron JMS567 (152d:0578 / 0x152d 0x0578) which could be perhaps updated, but I was not able to test it as the update tool needs an ARM CPU. Now I'm using two different adapters which both use the Asmedia ASM1051E / ASM1053E / ASM1153 / ASM1153E and they passthrough all commands.

You can check the bridge chip of your USB SATA adapter / enclosure as follows:

lsusb -v | grep -E ': ID |idVendor|idProduct'

Which returns something like:

Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
  idVendor           0x174c ASMedia Technology Inc.
  idProduct          0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge

回复收藏 0 原文