前置き
あ・・・ありのまま 今 起こった事を話すぜ!
「不要になったディスクを削除したと思ったら、必要なディスクのマウントが外れていた」
な・・・何を言っているのか わからねーと思うが
おれも 何をされたのか わからなかった・・・
もうちょっと詳しく
移行先のディスクを用意して、データの移行が終わった後にマウントポイントを入れ替える作業を行っていました。
disk_old: /mnt/data
disk_new: /mnt/data_new
となっているところを
disk_old: /mnt/data_new
disk_new: /mnt/data
とするようなイメージですね。
(なぜこんな移行をしているかはさておき)削除するディスクの指定以外はそんなにリスクもない作業の認識でした。
ところが入れ替え後の動作確認も終わったので、不要になったディスク(disk_old)を削除したところ、disk_newがアンマウントされるという悲劇が発生。
さらにマウントが外れたことに気づいて再度マウントしようとしても即時でアンマウントされるというおまけ付き。
原因とか調べた結果、何ともいえない気持ちになったので記事にして供養します。。
再現してみる
前提
実際には物理ディスクだったのですが、LVMでも再現できたので検証機では以下の感じで。
vg01がdisk_old、vg02がdisk_newの想定です。
[root@svr00 ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv01 vg01 -wi-ao---- 1.00g
lv01 vg02 -wi-ao---- 1.00g
/dev/mapper/vg01-lv01 /mnt/data xfs defaults 0 0
/dev/mapper/vg02-lv01 /mnt/data_new xfs defaults 0 0
それぞれファイルを配置してどちらのディスクかわかるように準備。
[root@svr00 ~]# cat /mnt/data/info.txt
OLD
[root@svr00 ~]# cat /mnt/data_new/info.txt
NEW
マウントポイントを入れ替える
マウントしているディスクを外し、fstabを更新して再マウント。
[root@svr00 ~]# umount /mnt/data
[root@svr00 ~]# umount /mnt/data_new
[root@svr00 ~]# df -h | grep /mnt/data
[root@svr00 ~]#
-/dev/mapper/vg01-lv01 /mnt/data xfs defaults 0 0
-/dev/mapper/vg02-lv01 /mnt/data_new xfs defaults 0 0
+/dev/mapper/vg02-lv01 /mnt/data xfs defaults 0 0
+#/dev/mapper/vg01-lv01 /mnt/data_new xfs defaults 0 0
入れ替わっていることが確認できます。
[root@svr00 ~]# mount /mnt/data
[root@svr00 ~]# df -h | grep /mnt/data
/dev/mapper/vg02-lv01 1014M 33M 982M 4% /mnt/data
[root@svr00 ~]# cat /mnt/data/info.txt
NEW
いざディスクを削除
この状態で使用していないvg01をdeactivateすると、関係ないvg02のマウントが外れます。
[root@svr00 ~]# vgchange -an vg01
0 logical volume(s) in volume group "vg01" now active
[root@svr00 ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv01 vg01 -wi------- 1.00g
lv01 vg02 -wi-ao---- 1.00g
[root@svr00 ~]# df -h | grep /mnt/data
[root@svr00 ~]#
手動でマウントコマンドを実行してもマウントできません。
[root@svr00 ~]# mount /mnt/data
[root@svr00 ~]# df -h | grep /mnt/data
[root@svr00 ~]#
dmesgを見てみるとマウントは実行されているのですが、即アンマウントが走っていることがわかります。
[Wed Apr 28 01:56:22 2021] XFS (dm-1): Mounting V5 Filesystem
[Wed Apr 28 01:56:22 2021] XFS (dm-1): Ending clean mount
[Wed Apr 28 01:56:22 2021] XFS (dm-1): Unmounting Filesystem
syslogにもコマンドにもエラー情報がないので初見だとホントポルナレフです。。
結局どうしたか
神のお告げにあるワークアラウンドを実行して再マウントできました。
[root@svr00 ~]# systemctl daemon-reload
[root@svr00 ~]# mount /mnt/data
[root@svr00 ~]# df -h | grep /mnt/data
/dev/mapper/vg02-lv01 1014M 33M 982M 4% /mnt/data
対処時点では「なんでdaemon-reloadで復旧するんだよ」と思ったんですが、よくよく調べてみたところ、systemd管理下だとfstabに記載されているエントリのマウントは実はsystemdで管理/監視されていて/run/systemd/generator
配下に動的生成されたUnitファイルが配置されています。
# Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
[Mount]
What=/dev/mapper/vg01-lv01
Where=/mnt/data
Type=xfs
これがfstabを書き換えたときに即時で反映されるわけではないので、何も知らないとWhat
に指定されているデバイスが古いままの状態になり、
- 不要になったディスク(=古いデバイス)を削除する
-
What
に指定されているデバイスがなくなったことをsystemdが検知 - systemd「デバイスないからアンマウントしとくで!」
という動作になった模様。
systemctl daemon-reload
を実行することでfstabのエントリをもとにUnitファイルが更新されてWhat
が新しいデバイスを向くので、sytemdによるアンマウントが動かなくなる、と。
これはちゃんと把握してないとわからんですよ・・・
結論
systemd管理下でfstabを更新したらsystemctl daemon-reload
を実行しませう