Когда вы говорите, что пробовали 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
Который, кажется, получает исчерпывающий список всех вещей, которые будут обращаться к дескриптору прямо или косвенно.