Я использую Ansible для настройки сервера. Этот сервер работает на AWS Ec2, и я подключаю к нему четыре диска EBS.
Когда я запускаю свой доступный 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, подписи программных рейдов или несоответствие в таблицах bios / uefi. Хорошая идея обнулить начало диска.
Если вы используете wipefs для этого (вместо dd) вы получаете дополнительное преимущество, заключающееся в том, что он использует ioctl, чтобы сообщить ядру, что нужно перезагрузить его представление о разделах диска.
Я думаю, что инструменты файловой системы, а также file команда читает непосредственно с диска и поэтому не знает о состоянии ядра. Я думаю, что код обнаружения файловой системы fsck также выполняет только элементарную проверку, чтобы найти тип, в котором отсутствует запись fstab для файловой системы. Контрольный двоичный файл такой же для ext2-ext4, поэтому, если fsck находит тип в fstab, он запускает команду именно с этим типом (fsck.ext4), однако, если он не находит тип, он проверяет начало на наличие подписи файловой системы и для любой из версий ext2 запускает инструмент fsck.ext2 (который проверяет более конкретную версию).