デバイスの電源を入れ直した後、間違ったNVMeデバイスにバインドポイントをマウントする場合

デバイスの電源を入れ直した後、間違ったNVMeデバイスにバインドポイントをマウントする場合

私はオールフラッシュストレージアプリケーションを開発しています。 NVMeデバイスの電源をオフまたはオンにすると、マウントバインディングが奇妙な動作をすることがわかりました。ディストリビューション: SUSE Linux Enterprise Server 15 SP4 5.14.21-150400.24.46-デフォルト

/dev/nvme10n1p1 パーティションを /mnt/10n1p1 にマウントします。

# mount --bind /dev/nvme10n1p1 /mnt/10n1p1
# lsblk /mnt/10n1p1
NAME       MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme10n1p1 259:11   0  3.6T  0 part

# stat /dev/nvme10n1p1
  File: /dev/nvme10n1p1
  Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 5h/5d   Inode: 23620       Links: 1     Device type: 103,b

# stat /mnt/10n1
  File: /mnt/10n1
  Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 5h/5d   Inode: 23620       Links: 1     Device type: 103,b

ホットプラグまたはパワーサージをシミュレートするために、短時間NVMEデバイスの電源をオフまたはオンにします。

# ls -lat /sys/block | grep "nvme10n1"
.../0000:be:00.0/nvme/nvme2/nvme10n1
# lspci -vmms 0000:be:00.0
...PhySlot:        168
# date && echo 0|sudo tee /sys/bus/pci/slots/${PHYSLOT}/power
# sleep 5
# date && echo 1|sudo tee /sys/bus/pci/slots/${PHYSLOT}/power

電源を入れ直した後、電源を入れたばかりの新しいドライブにバインディングポイントをマウントします。

# lsblk /mnt/10n1
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme30n2     259:11   0  3.6T  0 disk
└─nvme30n2p1 259:51   0  3.6T  0 part

# stat /dev/nvme30n2
  File: /dev/nvme30n2
  Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 5h/5d   Inode: 24836       Links: 1     Device type: 103,b

事前テストを終えた後、元のドライブの電源が切れてから短時間であっても、マウントバインドが電源を入れた別のドライブを指すことができることがわかりました。

# mount --bind  /dev/nvme0n1p1 /mnt/0n1
# lsblk 0n1
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1p1 259:44   0  3.6T  0 part
# nvme id-ctrl /dev/nvme0n1 | grep sn
sn:       : PHLJ043200234P0DGN
# nvme id-ctrl /dev/nvme1n1 | grep sn
sn:       : PHLJ043105AU4P0DGN

# PHYSLOT_0=195
# PHYSLOT_1=194
# date && echo 0|sudo tee /sys/bus/pci/slots/${PHYSLOT_1}/power
# sleep 5
# date && echo 0|sudo tee /sys/bus/pci/slots/${PHYSLOT_0}/power
# sleep 5
# date && echo 1|sudo tee /sys/bus/pci/slots/${PHYSLOT_1}/power
# sleep 5
# date && echo 1|sudo tee /sys/bus/pci/slots/${PHYSLOT_0}/power

# lsblk /mnt/0n1
NAME       MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme31n2p1 259:44   0  3.6T  0 part

# nvme id-ctrl /dev/nvme31n2 | grep sn
sn        : PHLJ043105AU4P0DGN
# nvme id-ctrl /dev/nvme32n2 | grep sn
sn        : PHLJ043200234P0DGN

停電/オン後、マウントポイントのinode番号は新しいドライブデバイスのinode番号とは異なりますが、マウントポイントのinodeと新しいドライブデバイスのinodeは同じマイナー番号を共有することがわかりました。これが元のマウントポイントが新しいドライブデバイスにアクセスしてデータの破損を引き起こす可能性がある理由だと思います。私の考えでは、マウントポイントが電源を切ったドライブのインデックスへの参照を保持していたため、インデックスノードは削除されていないようです。その後、新しいドライブの電源が入り、元のドライブと同じリサイクルマイナー番号が得られます。この動作が予想されるのか、バインディングインストールの制限やバグなのかはわかりません。

ベストアンサー1

これはLinuxカーネルbdevライフサイクルのバグで、バージョン5.15で修正されました。

関連パッチリンクここ

おすすめ記事