☰

为什么在 RHEL7 ec2 实例上创建 ext4 文件系统后缺少 UUID

tag-icon • tag-icon filesystems ext4 rhel7 uuid
为什么在 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)

所以有些事情不对劲

答案1

如果/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 工具（它将检查更具体的版本）。

相关内容