1. はじめに
1-1 ご挨拶
初めまして、井村と申します。
LinuxのAzure VMにおいて、データディスクを追加後、OS上でファイルシステム、マウント等の作業を行います。Azure VMの再起動後にマウントが解除される問題が発生しました。
本記事では、その原因と対策をまとめます。
2. 手順
下記の通り「/dev/nvme0n1」が追加のデータディスクになります。
ファイルシステムの作成、マウント、再起動後もデータディスク接続されるようfstabにデバイスを登録します。
bash
# ブロックデバイスの一覧を確認
root@vm-imura-test:~# lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
/dev/sr0 11:0 1 628K 0 rom
/dev/nvme0n1 259:0 0 32G 0 disk
/dev/nvme0n2 259:1 0 30G 0 disk
tq/dev/nvme0n2p1 259:2 0 29G 0 part /
tq/dev/nvme0n2p14 259:3 0 4M 0 part
tq/dev/nvme0n2p15 259:4 0 106M 0 part /boot/efi
mq/dev/nvme0n2p16 259:5 0 913M 0 part /boot
# マウントポイントを作成
root@vm-imura-test:~# ls -l /opt
total 0
root@vm-imura-test:~# mkdir /opt/mount
# ファイルシステムの作成
root@vm-imura-test:~# mkfs.ext4 /dev/nvme0n1
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 8388608 4k blocks and 2097152 inodes
Filesystem UUID: 566f2820-7282-4b27-af27-0ed31cbeaa75
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624
Allocating group tables: done
Writing inode tables: done
Creating journal (65536 blocks):
done
Writing superblocks and filesystem accounting information: done
# マウントを実施
root@vm-imura-test:~# mount /dev/nvme0n1 /opt/mount
# マウントの確認
root@vm-imura-test:~# df -h | grep /opt/mount
/dev/nvme0n1 32G 24K 30G 1% /opt/mount
# テストファイルの作成、確認
root@vm-imura-test:~# echo "This is a test file." > /opt/mount/testfile.txt && cat /opt/mount/testfile.txt
This is a test file.
root@vm-imura-test:~#
# fstabの設定
root@vm-imura-test:~# echo '/dev/nvme0n1 /opt/mount ext4 defaults 0 0' | sudo tee -a /etc/fstab
/dev/nvme0n1 /opt/mount ext4 defaults 0 0
root@vm-imura-test:~#
3. 検証
再起動後、マウントが解除されテストファイルが見つからない状態になりました。
bash
root@vm-imura-test:~# lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
/dev/nvme0n1 259:0 0 30G 0 disk
tq/dev/nvme0n1p1 259:2 0 29G 0 part /
tq/dev/nvme0n1p14 259:3 0 4M 0 part
tq/dev/nvme0n1p15 259:4 0 106M 0 part /boot/efi
mq/dev/nvme0n1p16 259:5 0 913M 0 part /boot
/dev/nvme0n2 259:1 0 32G 0 disk
root@vm-imura-test:~# ls -l /opt/mount/
total 0
4. 原因と対策
4-1 原因
原因は以下公式ドキュメントにありました。
Linux のデバイス パスは、再起動前後の一貫性が保証されていません。この問題は、Linux のデバイス スキャンが非同期で行われるように SCSI サブシステムでスケジュールされているために発生します。 その結果、デバイスのパス名は再起動の前後で変わることがあります。
4-2 対策
対策として、fstabにはデバイス名ではなくUUIDを指定します。
bash
# UUIDの確認
root@vm-imura-test:~# blkid
/dev/nvme0n1p16: LABEL="BOOT" UUID="4e0b0f7d-f018-493d-b384-d56a4d4661bd" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="bc888243-c7df-4555-b820-0fa1621cf3e0"
/dev/nvme0n1p1: LABEL="cloudimg-rootfs" UUID="fad0ebd7-fc6c-42fe-a34d-4e8d2f07946f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="625cad27-7b63-4e5e-8bbd-6efc33b38415"
/dev/nvme0n1p15: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="B0C0-7511" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="d403963f-6b02-4be2-96ef-428181705f25"
/dev/nvme0n2: UUID="566f2820-7282-4b27-af27-0ed31cbeaa75" BLOCK_SIZE="4096" TYPE="ext4"
# /etc/fstabの修正
root@vm-imura-test:~# vim /etc/fstab
# /etc/fstabの確認
root@vm-imura-test:~# cat /etc/fstab
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
UUID=fad0ebd7-fc6c-42fe-a34d-4e8d2f07946f / ext4 discard,commit=30,errors=remount-ro 0 1
LABEL=BOOT /boot ext4 defaults,discard 0 2
UUID=B0C0-7511 /boot/efi vfat umask=0077 0 1
UUID=566f2820-7282-4b27-af27-0ed31cbeaa75 /opt/mount ext4 defaults 0 0
再起動を複数回実施した結果が以下になります。
/opt/mountのマウントが/dev/nvme0n1 または /dev/nvme0n2 になる場合がありますが、テストファイルを確認することができます。
bash
# 再起動後
root@vm-imura-test:~# ls -l /opt/mount/
total 20
drwx------ 2 root root 16384 Nov 19 05:35 lost+found
-rw-r--r-- 1 root root 21 Nov 19 05:43 testfile.txt
root@vm-imura-test:~# lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
/dev/nvme0n1 259:0 0 30G 0 disk
tq/dev/nvme0n1p1 259:2 0 29G 0 part /
tq/dev/nvme0n1p14 259:3 0 4M 0 part
tq/dev/nvme0n1p15 259:4 0 106M 0 part /boot/efi
mq/dev/nvme0n1p16 259:5 0 913M 0 part /boot
/dev/nvme0n2 259:1 0 32G 0 disk /opt/mount
root@vm-imura-test:~#
# 再起動後
root@vm-imura-test:~# ls -l /opt/mount/
total 20
drwx------ 2 root root 16384 Nov 19 05:35 lost+found
-rw-r--r-- 1 root root 21 Nov 19 05:43 testfile.txt
root@vm-imura-test:~#
root@vm-imura-test:~# lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
/dev/nvme0n1 259:0 0 32G 0 disk /opt/mount
/dev/nvme0n2 259:1 0 30G 0 disk
tq/dev/nvme0n2p1 259:2 0 29G 0 part /
tq/dev/nvme0n2p14 259:3 0 4M 0 part
tq/dev/nvme0n2p15 259:4 0 106M 0 part /boot/efi
mq/dev/nvme0n2p16 259:5 0 913M 0 part /boot
root@vm-imura-test:~#
以上で対策は終了になります。
5. 終わり
本記事を最後まで読んでいただき、ありがとうございました。
本記事が同様の問題解決に役立てば幸いです。