У меня есть виртуальная машина с Centos 7, на которой я хочу смонтировать несколько разделов ext4. Физические диски - это фактически жесткие диски, предоставленные vSphere. Все диски расположены на одном NAS - поэтому три рабочих диска (a, c, d) практически идентичны проблемным (e, f, g).
содержимое fstab:
UUID=b6ebbca4-71d0-4d2e-bc1a-e465e5190698 /boot ext4 defaults 1 2
UUID=2c3ab9f5-60a6-4a79-ada3-84737eef7748 / ext4 defaults 1 1
UUID=e130758c-5108-44de-bbd8-7e003c9072bc swap swap defaults 0 0
UUID=decbbdb6-8362-41ef-aa72-83066c172913 /home ext4 defaults 1 2
UUID=5717b613-a9f4-43c9-95d2-cfbbb891bd19 /apps_home ext4 defaults 1 2
UUID=e24df090-2dda-404c-8944-a28bd37d6c5e /apps/var/progress ext4 defaults 1 2
UUID=5f254c77-a91d-4255-8315-9325ddb7a9d8 /apps/var/standard ext4 defaults 1 2
UUID=746c70c1-002a-4249-a06f-df393a99252c /apps/var/custom ext4 defaults 1 2
lsblk -o '+UUID,FSTYPE' вывод:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID FSTYPE
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1G 0 part /boot b6ebbca4-71d0-4d2e-bc1a-e465e5190698 ext4
└─sda2 8:2 0 49G 0 part / 2c3ab9f5-60a6-4a79-ada3-84737eef7748 ext4
sdb 8:16 0 40G 0 disk
└─sdb1 8:17 0 40G 0 part [SWAP] e130758c-5108-44de-bbd8-7e003c9072bc swap
sdc 8:32 0 50G 0 disk
└─sdc1 8:33 0 50G 0 part /home decbbdb6-8362-41ef-aa72-83066c172913 ext4
sdd 8:48 0 600G 0 disk
└─sdd1 8:49 0 600G 0 part /apps_home 5717b613-a9f4-43c9-95d2-cfbbb891bd19 ext4
sde 8:64 0 250G 0 disk
└─sde1 8:65 0 250G 0 part /apps/var/progress e24df090-2dda-404c-8944-a28bd37d6c5e ext4
sdf 8:80 0 1T 0 disk
└─sdf1 8:81 0 1024G 0 part /apps/var/standard 5f254c77-a91d-4255-8315-9325ddb7a9d8 ext4
sdg 8:96 0 2T 0 disk
└─sdg1 8:97 0 2T 0 part /apps/var/custom 746c70c1-002a-4249-a06f-df393a99252c ext4
sr0 11:0 1 1024M 0 rom
Проблема в том, что fstab не монтирует три последних раздела (которые должны быть смонтированы в /apps/var/progress /apps/var/standard и /apps/var/custom соответственно) последовательно после перезагрузок. Время от времени он монтирует один из них (если какой-либо из этих трех монтируется, это совершенно случайно, и всегда монтируется только один или ни один). Остальные разделы монтируются последовательно без каких-либо проблем.
Параметр mount -a ничего не делает, однако $ mount / dev / sde1 (или dev / sdf1 или dev / sdg1) работает как шарм. Точно так же установка с помощью команды $ mount / apps / var / progress тоже работает без проблем.
На данный момент я просто использовал cron для монтирования этих трех разделов после каждой перезагрузки, но в конечном итоге я хотел бы знать основную причину этого странного поведения.
Я попытался заменить UUID именами / dev / sd *, попытался поставить кавычки.
mount всегда показывает, что разделы смонтированы в правильные каталоги, однако umount сообщает, что раздел в данный момент не смонтирован.
Я заметил, что три проблемных раздела ранее имели файловую систему ext3 и каким-то образом были преобразованы в ext4. Кроме того, для этих трех разделов blkid показывает PARTUUID в дополнение к UUID (я думаю, что они ранее использовались с centos 6)
mount всегда показывает, что разделы смонтированы в правильных каталогах, однако umount сообщает, что раздел в данный момент не смонтирован.
Из обсуждения в комментариях я считаю, что ваша система представляет такое поведение из-за /etc/mtab являясь обычным файлом, а не символической ссылкой, нацеленной на /proc/self/mount. Я предлагаю вам восстановить символическую ссылку, как описано в этом Решение Red Hat:
В Red Hat Enterprise Linux 7
/etc/mtabбольше не плоский файл, это символическая ссылка на/proc/self/mounts. Если сервис по какой-то причине используетsedкоманда для доступа или изменения/etc/mtab, возможно, он удалит символическую ссылку и создаст плоский файл. Это, в свою очередь, приводит к тому, что сервер не загружается полностью, он переходит в аварийный режим,dfвывод показывает все смонтированные, но если/proc/mountsпроверено не будет ничего кроме/установлен.
В итоге из обсуждения в комментариях:
По сути, ваша проблема заключалась в том, что вы использовали символические ссылки в путях к точкам монтирования, и при загрузке система не смогла правильно следовать им, чтобы распознать результат как «вложенные монтирования». Поэтому systemd не смонтировал ваши файловые системы в правильном последовательном порядке, чтобы справиться с этой зависимостью.
У вас есть точка монтирования /apps_home
У вас есть символическая ссылка /apps --> /apps_home/apps
И вы также должны попытаться смонтировать тома на /apps/var/progress /apps/var/custom и /apps/var/custom
Проблема в том, что точки монтирования /apps/var/[custom|progress|standard] не существует, пока /apps_home установлен.
Решение:
Оставьте символическую ссылку, но смонтируйте свои файловые системы на фактических путях к каталогам целевой символической ссылки: то есть преобразуйте записи fstab в:
UUID=5717b613-a9f4-43c9-95d2-cfbbb891bd19 /apps_home ext4 defaults 1 2
UUID=e24df090-2dda-404c-8944-a28bd37d6c5e /apps_home/apps/var/progress ext4 defaults 1 2
UUID=5f254c77-a91d-4255-8315-9325ddb7a9d8 /apps_home/apps/var/standard ext4 defaults 1 2
UUID=746c70c1-002a-4249-a06f-df393a99252c /apps_home/apps/var/custom ext4 defaults 1 2
systemd-fstab-generato сгенерирует необходимые файлы модулей монтирования и systemd.mount неявно добавит правильные зависимости:
Если монтируемый модуль находится ниже другого монтируемого модуля в иерархии файловой системы, автоматически создаются как зависимость требований, так и зависимость порядка между обоими модулями.
Альтернатива: удалите записи из / etc / fstab и создайте свои собственные файлы модулей монтирования и вручную настройте требования и зависимости порядка, чтобы гарантировать, что /apps/var/progress /apps/var/custom и /apps/var/custom не садись раньше /apps_home.