為什麼在 RHEL7 ec2 實例上創建 ext4 文件系統後 UUID 失去

我正在使用 Ansible 配置伺服器。該伺服器在 AWS Ec2 上執行，我將連接四個 EBS 驅動器。

當我執行我的 ansible playbook 時，它大約有 50% 的時間會失敗。失敗是當我將路徑安裝到新格式化的驅動器時。在調查時，我注意到四個驅動器之一似乎沒有文件系統並且缺少它的 UUID。Ansible 在創建文件系統的任務中沒有顯示任何錯誤。

---

任務：

- name: Create File Systems
     filesystem:
       fstype: ext4
       dev: /dev/{{ item }}
     with_items: "{{ ansible_devices }}"
     register: filesystem
     when: item != "nvme0n1"

我跳過根卷^。

TASK [Create File Systems] ****************************************************************************************************************************************************************************************************************************************************************************************************
changed: [10.76.22.196] => (item=nvme3n1)
changed: [10.76.22.196] => (item=nvme4n1)
changed: [10.76.22.196] => (item=nvme1n1)
changed: [10.76.22.196] => (item=nvme2n1)
skipping: [10.76.22.196] => (item=nvme0n1)

因此，當它失敗並且我登錄進行調查時，我得到了這個……

[ec2-user@ip-10-76-22-196 ~]$ lsblk -f
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
nvme0n1
├─nvme0n1p1
└─nvme0n1p2 xfs          de4def96-ff72-4eb9-ad5e-0847257d1866 /
nvme1n1     ext4         35546ab6-8a1f-401f-97fa-7c9daf9005eb /couchbase/DATA
nvme2n1     ext4         379a603a-2726-437f-ad25-14fd43358e96 /couchbase/INDEX
nvme3n1     ext4         b0ceae1f-e902-44d5-a63f-2ef81bb62f21 /couchbase/LOGS
nvme4n1

接下來我嘗試再次創建文件系統

[root@ip-10-76-22-196 ~]# mkfs.ext4 /dev/nvme4n1
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1638400 inodes, 6553600 blocks
327680 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2155872256
200 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
       32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
       4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

[root@ip-10-76-22-196 ~]# lsblk -f
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
nvme0n1
├─nvme0n1p1
└─nvme0n1p2 xfs          de4def96-ff72-4eb9-ad5e-0847257d1866 /
nvme1n1     ext4         35546ab6-8a1f-401f-97fa-7c9daf9005eb /couchbase/DATA
nvme2n1     ext4         379a603a-2726-437f-ad25-14fd43358e96 /couchbase/INDEX
nvme3n1     ext4         b0ceae1f-e902-44d5-a63f-2ef81bb62f21 /couchbase/LOGS
nvme4n1

但沒有運氣=/

我還嘗試了其他方法來獲取這些資訊。

[ec2-user@ip-10-76-22-196 ~]$ ls /dev/disk/by-uuid/
35546ab6-8a1f-401f-97fa-7c9daf9005eb  379a603a-2726-437f-ad25-14fd43358e96  b0ceae1f-e902-44d5-a63f-2ef81bb62f21  de4def96-ff72-4eb9-ad5e-0847257d1866

fsck似乎認為它的ext2？

[ec2-user@ip-10-76-22-196 ~]$ fsck -N /dev/nvme4n1
fsck from util-linux 2.23.2
[/sbin/fsck.ext2 (1) -- /dev/nvme4n1] fsck.ext2 /dev/nvme4n1
[ec2-user@ip-10-76-22-196 ~]$ fsck -N /dev/nvme3n1
fsck from util-linux 2.23.2
[/sbin/fsck.ext4 (1) -- /couchbase/LOGS] fsck.ext4 /dev/nvme3n1
[ec2-user@ip-10-76-22-196 ~]$ lsblk -f
NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
nvme0n1
├─nvme0n1p1
└─nvme0n1p2 xfs          de4def96-ff72-4eb9-ad5e-0847257d1866 /
nvme1n1     ext4         35546ab6-8a1f-401f-97fa-7c9daf9005eb /couchbase/DATA
nvme2n1     ext4         379a603a-2726-437f-ad25-14fd43358e96 /couchbase/INDEX
nvme3n1     ext4         b0ceae1f-e902-44d5-a63f-2ef81bb62f21 /couchbase/LOGS
nvme4n1

最後，我發現了這個…

[ec2-user@ip-10-76-22-196 ~]$ sudo sudo file -s /dev/nvme*
/dev/nvme0:     ERROR: cannot read (Invalid argument)
/dev/nvme0n1:   x86 boot sector; partition 1: ID=0xee, active, starthead 0, startsector 1, 20971519 sectors, code offset 0x63
/dev/nvme0n1p1: data
/dev/nvme0n1p2: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
/dev/nvme1:     ERROR: cannot read (Invalid argument)
/dev/nvme1n1:   Linux rev 1.0 ext4 filesystem data, UUID=35546ab6-8a1f-401f-97fa-7c9daf9005eb (needs journal recovery) (extents) (64bit) (large files) (huge files)
/dev/nvme2:     ERROR: cannot read (Invalid argument)
/dev/nvme2n1:   Linux rev 1.0 ext4 filesystem data, UUID=379a603a-2726-437f-ad25-14fd43358e96 (needs journal recovery) (extents) (64bit) (large files) (huge files)
/dev/nvme3:     ERROR: cannot read (Invalid argument)
/dev/nvme3n1:   Linux rev 1.0 ext4 filesystem data, UUID=b0ceae1f-e902-44d5-a63f-2ef81bb62f21 (needs journal recovery) (extents) (64bit) (large files) (huge files)
/dev/nvme4:     ERROR: cannot read (Invalid argument)
/dev/nvme4n1:   Linux rev 1.0 ext4 filesystem data, UUID=caf9638a-9d10-482e-a554-ae8152cd2fdb (extents) (64bit) (large files) (huge files)

所以有些事情是不對的

如果/dev/disk/by-uuid或lsblk不顯示文件系統，則可能是核心未正確辨識分區類型，或者核心視圖未在mkfs.

在許多情況下，磁碟上的垃圾會導致問題，包括外部 lvm ID、軟體 raid 簽名或 bios/uefi 表中的不匹配。清空磁碟的開頭是個好主意。

如果您使用wipefs它（而不是dd），您將獲得額外的好處，它使用 ioctl 來告訴核心實際重新載入其磁碟分區視圖。

我認為文件系統工具和file命令直接從磁碟讀取，因此不知道核心狀態。我認為 fsck 的文件系統檢測程式碼也只是進行初步檢查以查找文件系統沒有 fstab 條目的類型。ext2-ext4 的檢查二進製文件是相同的，因此如果 fsck 在 fstab 中找到該類型，它會啟動一個具有該類型的命令fsck.ext4（ ext2 版本它啟動 fsck.ext2 工具（它將檢查更具體的版本）。

引用自：https://serverfault.com/questions/952061