Linuxデバイス名の確認方法

みなさん、こんにちは。

TVS-672XTで発生している問題についてQNAPサポートとやり取りしています。NASのロードアベレージ(負荷平均)が急激に上昇し始めます。ほとんどがI/Oタスクによって消費されています。昨夜は110から150くらいまで上がっていて、特に何も負荷をかけるようなことはしていませんでした。SSH経由で再起動することはできましたが、数時間かかりました。

数日前、QNAPサポートからエスカレーションチームが「/dev/md13」がほぼ満杯で、ほぼ満杯のドライブはこのような問題を引き起こす可能性があると指摘されました。彼らはこのデバイスからデータを削除するように言いました。

これは驚きでした。なぜなら、私は8TBのドライブを6台RAID5で構成していて、バックアップデータは合計12~13TB程度しかありません。どのドライブも満杯には程遠い状態です。

SSHシェルで「cd」コマンドで /dev/md13 に入ろうとすると「ディレクトリではありません」と表示されます。確かに「デバイス」です。でも、これが何なのか分かりません。Googleで調べると、/dev/に「md」と付いているデバイスはRAIDアレイ(md = マルチディスク)だと出てきます。しかし、私のRAIDは全然満杯ではありません。

では、これは一体何なのでしょうか?LinuxのQTSでこの特定のデバイスがどのドライブやボリュームなどに関連しているのか、どうやって調べればいいでしょうか?

今、QNAPサポートから「dev/md13」はシステム関連であり、未使用のアプリを削除するように言われています。面白いことに、QNAPアプリは3~4個程度しか使っておらず、それ以外は基本的な必要なものだけです。

では、SSHでアクセスして、何が容量を使っているのか確認する方法はありますか?

md9とmd13は各ディスクのOSパーティションです

md13は/mnt/extにマウントする必要があります

ありがとうございます。Linuxのコマンドラインはあまり得意ではありません。現在の状況は以下の通りです…

[jono@NA9D-NAS-3 ext]$ ls -la
total 24
drwxr-xr-x  4 admin administrators  4096 2025-05-18 20:27 ./
drwxr-xr-x 14 admin administrators   320 2025-07-23 07:58 ../
-rw-r--r--  1 admin administrators     0 2025-05-18 20:27 addon_flag
-rw-r--r--  1 admin administrators     0 2025-05-18 20:27 debug_flag
drwx------  2 admin administrators 16384 2025-05-18 20:27 lost+found/
drwxr-xr-x 33 admin administrators  4096 2025-07-23 07:58 opt/

あまりファイルはありません。ボリュームの合計容量と利用可能な容量を確認するにはどうすればいいですか?lost+foundが原因だと思っていますが、アクセスできません。権限がありませんと表示されます。「cd」コマンドでsudoが効かないようです…

「admin」ユーザーを使用しましたか?

いいえ。私のユーザーアカウントは管理者です。もしかすると、管理者ユーザーを再度有効にする必要があるかもしれません。

adminは常に有効にしておくべきです。2022年のランサム攻撃時にQNAPがadminを無効化したのは無意味なパニック反応でした(このユーザーは内部プロセスに必要なので、無効化は見せかけに過ぎず、ランサムウェアは「無効化された」ユーザーを結局悪用しました)。

OK。うまくいきました。さて、ボリュームの合計容量と残り容量を確認するにはどうすればよいですか?あまり多くはないように見えますが…

lost+foundには何も入っていませんでしたが、最も使用量が多いと表示されています。

a

df -h

で、さまざまなマウントが表示されるはずです

Filesystem                Size      Used Available Use% Mounted on
/dev/md9                493.5M    186.8M    306.6M  38% /mnt/HDA_ROOT
/dev/md13               416.7M    383.8M     32.9M  92% /mnt/ext

こちら(TS-853BU)ではこのように表示されます

はい。md13については私も同じです。

/dev/md13               417.0M    384.6M     32.4M  92% /mnt/ext

あなたのものと同じですね。なので、なぜQNAPがこれを問題だと言ってCPU使用率の急上昇の原因だとするのかよく分かりません…

これは問題になる可能性がありますか?これは何ですか?

Filesystem                Size      Used Available Use% Mounted on
none                    432.0M    361.4M     70.6M  84% /

それはrootのはずです。私のものもほぼ同じサイズですが、問題ありません。

Filesystem                Size      Used Available Use% Mounted on
none                    400.0M    330.8M     69.2M  83% /

QNAPサポートがそれについて何を意味していたのかはよく分かりません。

OK。サポートが問題の解決にならない関係ない話ばかり持ち出すの、本当に困るよね…

実際、この問題は md13 とは関係ない可能性があると考えています。混乱を招いてしまい、本当に申し訳ありません。

サポートチームのマネージャーがチームに連絡を取り、状況を十分に把握した上で、引き続き問題解決のお手伝いをさせていただきます。

ご迷惑をおかけしたことを心よりお詫び申し上げます。ご理解いただき、ありがとうございます。

ありがとうございます。サポートチームが推測ではなく、意味のある解決策を提供してくれると非常に助かります。実際にサポートチケットにはこう書かれていました:

エスカレーションチームが /dev/md13 がほぼ満杯であり、高負荷を引き起こす可能性があることを通知しました。
md13 の空き容量を確保してください。
また、レプリケーションや TimeMachine バックアップ中は高負荷が予想されます。
アイドル時には負荷は通常通りになるはずです。

さらに、彼らはこうも言いました:

エスカレーションチームは未使用のアプリケーションをすべて削除するよう助言しました。
/dev/md13 はシステム関連パーティションで、未使用のアプリによって容量が埋まる可能性があります。
未使用のアプリをすべて削除して、効果があるか教えてください。

つまり、「ファイルを削除してください」と言うのですが、ユーザーがアクセスできないデバイスです。そして「未使用のアプリを削除してください。それが問題です」とも言います。いや、違います。このマシンにはほとんどアプリがインストールされていません。これはただのデタラメですし、これが「エスカレーション」チーム、つまり本来なら知識のあるサポート担当者からの回答なのです。

そして「Time Machine バックアップが使用率を急増させることがある」とも言います。本当に?しかもこんなに急増するんですか?ロードアベレージが 110?

ロードアベレージが 110(最高で 150 も見ました)が未使用アプリによって引き起こされるんですか?それはさすがに笑えます。

私はこの現象が起きたとき、CPUの平均値はユーザーとシステムでかなり低く、I/O で非常に高い(98%)ことを何度も指摘しています。つまり、何かが I/O の待機状態になっていて、それが何なのか本当に知りたいだけなのです!しかし、彼らはメモリテストをさせ(合格)、その後 md13 についての的外れな回答を提案してきました。誰も本当の原因を分かっていないように思えます…

上部では、アプリはシステムボリュームの隠し.qpkgフォルダーにインストールされます。(別のボリュームに移動できる/移動された場合を除く)そのため、インストールされたアプリがmd13を埋めることはありません(ただし、変更内容はqpkg.confファイルに記録されます)。

その通りです!サポートスタッフが自分たちのデバイスの使い方すら分かっていないみたいで、本当に怖いです。

CPU使用率が急激に上昇する件でチケットを開いています。ログも何度も提出しました。スナップショットレプリカの一部が失敗する件でも別のチケットを開いています。ログには誰も意味を説明できないエラーメッセージまであります。

「メモリチェックをしてください。あなたは当社の高額なメモリを使っていませんね」といったお決まりの返答ばかりです。メモリチェックはいつも問題ありません。

さらに、別の問題をテストしている間にサポートがメール設定を変更し、そのまま戻してくれませんでした!QNAP(キューナップ)はフォーラムで大きく謝罪してくれましたが、サポートチケットでは「誰がやったのか分かりません…」と言われました。

本当にサポートの質を疑いたくなります。