前置き

あ・・・ありのまま今　起こった事を話すぜ！

「不要になったディスクを削除したと思ったら、必要なディスクのマウントが外れていた」

な・・・何を言っているのか　わからねーと思うが　
おれも　何をされたのか　わからなかった・・・

もうちょっと詳しく

移行先のディスクを用意して、データの移行が終わった後にマウントポイントを入れ替える作業を行っていました。

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

/etc/fstab

/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 ~]#

/etc/fstab

-/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ファイルが配置されています。

/run/systemd/generator/mnt-data.mount

# 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を実行しませう