私は2台のアーカイブHDDを持っていますが、これはめったに使用しません(パーティションを手動でマウントするのは平均して週に1回未満です)。夜にコンピュータの電源を切るので、毎日の起動時にコンピュータがスピンアップしないようにしましたが、thatは難しすぎるようです: Linuxカーネルにパッチを適用する必要があります 。より悪いがより単純な代替手段として、起動直後にHDDをスリープ状態にする単純なsystemdユニットを作成しました(ExecStart=/usr/bin/hdparm -Y /dev/disk/by-id/...
およびWantedBy=multi-user.target
)。これはほぼ機能します。両方のディスクが起動時にスピンダウンします。 tty2の端末ログインでこれを確認しました:Sudo hdparm -C /dev/sd[bc]
レポートdrive state is: standby
。
ただし、グラフィカルシェルにログインすると、ディスクの1つが音声でスピンアップし、hdparmがdrive state is: active/idle
を報告します。これは、XFCEとKDE Plasma 5(最新のアップデートを含むManjaro GNU/Linux)と、同じシステムの別のユーザーの両方で発生します。ディスクが目覚めた後、手動でスリープ状態にし(hdparm -Y ...
)、コンピューターを再起動するまで二度と目覚めません。ログアウトしてからログインしても、別のユーザーであっても、ディスクを再度ウェイクアップすることはありません。
この覚醒ディスクは常に同じです。 ID(sdb <-> sdc)を交換したこれら2つのHDDのSATAケーブルを交換しようとしましたが、最初のグラフィカルログイン時に同じ物理HDDが起動されます。この覚醒ディスクは、最近購入したため(中古)、永続IDで構成ファイルのどこにも記載されていません。具体的には、スリープ状態を維持するディスクはSamsung HD103UJであり、最初のグラフィカルログイン時にウェイクアップするディスクはSamsungです。 HD154UI。
/ dev/sd [bc]アクセスをauditdで監視しています。ログは両方のディスクで実質的に同じです。まず、tty2コンソールにログインし、Sudo hdparm -C /dev/sd[bc]
を実行します。両方のディスクがスリープしています。次に、tty7に切り替えて、lightdm画面からXFCEにログインします。すぐにtty2に切り替えたところ、ディスクの1つがスリープ状態でなくなりました。これらのイベントに対応するSudo ausearch -f /dev/sdb
コマンド出力の本質:
comm="hdparm" exe="/usr/bin/hdparm"
comm="udisksd" exe="/usr/lib/udisks2/udisksd"
comm="hdparm" exe="/usr/bin/hdparm"
comm="udisksd" exe="/usr/lib/udisks2/udisksd"
comm="pool" exe="/usr/lib/udisks2/udisksd"
comm="pool" exe="/usr/lib/udisks2/udisksd"
...
等々。 comm="pool"
行は、ログに10分ごとに表示されます。または、gnome-disksの実行中に頻繁に表示されますが、comm="udisksd"
再起動するまで行は表示されません。 auditdがすべてのディスクアクセスを報告すると仮定すると、このcomm="udisksd"
がウェイクアップを担当する必要があります。しかし、なぜ2台のHDDのうち1台だけなのですか?おそらく、問題のあるHDDはhdparm
で構成でき、目覚めないようにできますか?
hdparm -I /dev/sdb
とhdparm -I /dev/sdc
の出力をmeldと比較しました。また、-Iv
の代わりに-i
、-iv
、および-I
オプションを試しました。違いは、一意の識別子、ディスクサイズ、ジオメトリにかなり限定されています。このウェイクアップの不整合を引き起こす可能性がある唯一の違いは、ファームウェアのリビジョンです:1AA覚醒していないディスク上の01118および1AG目覚めているものに01118。
udisksdは、サービスの開始時およびディスクのマウント/アンマウント時に、ext2、ext3、およびext4パーティションごとにdumpe2fs -h /dev/sd??
コマンドを呼び出します。私の目覚めているHDDにはext4パーティションが含まれているため、udisksd=> dumpe2fs
によって目覚めます。他のHDDにはext *パーティションがないため、udisksdによってウェイクアップされることはありません。
このudisksバグへのコメントでより多くの詳細を見つけることができます: https://github.com/storaged-project/udisks/issues/611 。このバグはudisks 2.8.4で修正されているため、無関係のパーティションがマウントまたはアンマウントされたときにHDDをウェイクアップしなくなりました。 udisksdが起動しても、同じHDDがまだウェイクアップしているので、このHDDをスリープ状態にする 2番目のsystemdユニット を保持する必要がありますudisks2サービスが開始された後。