追加したストレージがLinuxに認識されているか確認する実務手順

物理サーバーへのHDD増設、仮想マシンへのディスク追加、外付けSSDの接続——こうした作業の直後に「Linuxが本当に認識しているか」を確認することは実務の基本です。認識できていなければ、その先のパーティション作成もファイルシステム構築も始まりません。まず確認コマンドを実行し、その後に認識されなかった場合の対処へ進みます。

lsblkで接続ディスクを一覧確認する（最速）

最初に実行するのは lsblk です。カーネルが認識しているブロックデバイスをツリー形式で表示します。追加したディスクが /dev/sdb や /dev/sdc として現れていれば、OS側の認識は完了しています。

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL

出力例：

NAME   SIZE TYPE MOUNTPOINT MODEL
sda    500G disk            SAMSUNG_MZNLN512
├─sda1   1G part /boot
└─sda2 499G part /
sdb      2T disk            WDC_WD20EZAZ

sdb が表示されていれば増設ディスクはOSに認識済みです。MOUNTPOINT 列が空欄なのは正常——まだパーティションもマウントもしていない新品ディスクの状態です。MODEL 列に見覚えのない型番が表示された場合は、意図したディスクかどうかをシリアル番号レベルで照合してから作業を進めてください。

lsscsiでSCSI/SASデバイスの詳細情報を確認する

ベンダー名・型番・デバイスノードをまとめて確認したい場合は lsscsi が便利です。SATA/SAS問わず表示でき、ホスト番号・チャンネル・ターゲット・LUNの構造も把握できます。デフォルトではインストールされていないため、以下でパッケージを導入します。

# RHEL / AlmaLinux / Rocky Linux 系
sudo dnf install lsscsi

# Ubuntu / Debian 系
sudo apt install lsscsi

# 実行
lsscsi

[0:0:0:0]    disk    ATA      SAMSUNG MZNLN512 MAV2  /dev/sda
[1:0:0:0]    disk    ATA      WDC WD20EZAZ     0A80  /dev/sdb

角括弧内は [ホスト:チャンネル:ターゲット:LUN] を示します。SASエクスパンダー経由の多段構成や、マルチパス環境での同一デバイスの重複確認にも役立ちます。

/proc/scsi/scsiでカーネルの認識情報を直接読む

旧来から使われてきた /proc/scsi/scsi は、現代のカーネルでも有効です。仮想ファイルシステム上のこのファイルには、カーネルのSCSIサブシステムが把握しているデバイス情報がそのまま格納されています。

cat /proc/scsi/scsi

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: SAMSUNG MZNLN512    Rev: MAV2
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD20EZAZ       Rev: 0A80
  Type:   Direct-Access                    ANSI  SCSI revision: 05

Attached devices: の後に何も表示されない場合、カーネルはデバイスを認識できていません。この場合は後述の再スキャン手順に進みます。なお、NVMe（PCIe接続）SSDはSCSIサブシステムを使わないためここには現れず、/dev/nvme0n1 のような名前で lsblk にのみ表示されます。

dmesgとjournalctlでデバイス認識ログを確認する

ディスクを接続した直後のカーネルログには、認識の成否とデバイス名の割り当てが記録されています。認識に失敗した場合もその痕跡がここに残ります。

# カーネルログからSCSI・ディスク関連メッセージを抽出
dmesg | grep -iE 'scsi|sd[a-z]|ata[0-9]' | tail -30

# systemd環境ではjournalctlでも確認可能
journalctl -k --since "10 minutes ago" | grep -iE 'scsi|sd[a-z]'

ある運用現場では、ホットスワップ後に lsblk で見えないディスクがあり、dmesg を確認したところ I/O error, dev sdb が大量に記録されていた、という事例があります。ログを確認せずにパーティション作業へ進むと、ハードウェア障害をそのまま見逃すリスクがあります。

ディスクが認識されていない場合のSCSI再スキャン

仮想マシンへのディスク追加や、ホットプラグ対応サーバーへの物理ディスク挿入後に認識されない場合、SCSIホストに対して再スキャンを指示できます。再起動不要で反映できるため、稼働中のサーバーでも安全に実行できます。

# 接続されているSCSIホストを確認
ls /sys/class/scsi_host/

# 全ホストを順に再スキャン（"- - -" はチャンネル・ターゲット・LUNのワイルドカード）
for host in /sys/class/scsi_host/host*; do
  echo "- - -" | sudo tee "${host}/scan"
done

実行後、数秒待ってから再度 lsblk を実行します。新しいデバイス名（/dev/sdb など）が現れれば再スキャン成功です。

# 再スキャン後に確認
lsblk -o NAME,SIZE,TYPE,MODEL

再スキャンを行っても認識されない場合は、ハードウェア側の問題（ケーブル不良・コネクタ不良・電源不足・BIOS/UEFIレベルの未認識）を疑います。その際も dmesg のエラーメッセージが最初の手がかりになります。

注意： この再スキャン手順はSCSI/SATA接続のデバイスに有効です。NVMeはPCIeバスを使うため対象外です。NVMeのホットプラグ対応はサーバーの仕様書を確認してください。

デバイス名の固定と誤操作防止

Linuxのディスクデバイス名（sda/sdb）は、接続順や再起動のたびに変わることがあります。複数ディスクが接続された環境で誤ったデバイスを操作するとデータが失われます。作業前に /dev/disk/by-id/ や /dev/disk/by-path/ で永続的な識別子を確認する習慣を持つと安全です。

# ディスクの永続的な識別子を確認
ls -la /dev/disk/by-id/

# パーティション構成を確認してから作業開始
sudo fdisk -l /dev/sdb

ディスクの認識確認から作業開始までの流れをまとめると、lsblk で存在確認 → dmesg でエラーチェック → 必要なら再スキャン → /dev/disk/by-id/ で対象デバイスを特定 → fdisk -l でパーティション状態を確認、という順序になります。この確認ステップを省くと、誤デバイス操作によるデータ消失リスクが高まります。