Ошибку в fstab часто замечают, когда служба уже записала файлы в каталог без тома. Здесь — как подключить том и не потерять их.
Исправный том с неверной ссылкой в таблице лечат правкой таблицы. mkfs создаёт на томе новую пустую файловую систему и стирает данные. fsck ищет повреждения файловой системы, а при чужом UUID их нет; на смонтированной файловой системе он сам может их создать.
Файлы, которые служба записала без тома, лежат в каталоге на корневой файловой системе. После mount том их закроет: служба их не увидит, а место на корневой файловой системе они займут по-прежнему. Поэтому их убирают из каталога до подключения и кладут на том после.
Том с данными не монтируется: в fstab у него неверный UUID, а сам том исправен. Что сделаешь?
-
Том подключится до перезагрузки: таблица по-прежнему ссылается на чужой UUID, и при загрузке том снова не найдётся.
-
fsckищет повреждения файловой системы, а их нет:findmnt --verifyуказывает на источник, которого нет на машине. -
mkfsсоздаёт новую пустую файловую систему: данные пропадут, а у тома появится новый UUID. Ошибка в ссылке, её и правят.
Исправный том с неверной ссылкой лечат правкой ссылки. findmnt --verify подтверждает таблицу, а findmnt --mountpoint и файлы тома — результат.
Бывает, что том уже подключили, а файлы остались под ним. Пока том подключён, до них не добраться: том придётся отключить. umount откажет с target is busy, если том кто-то использует, — например, твоя оболочка стоит внутри каталога. Выйди из него (cd ~) и повтори.
В упражнении коллега уже исправил таблицу и подключил том по ней, а два ночных отчёта остались под ним.
Достань отчёты из-под тома
Утром коллега исправил таблицу /srv/storage-lab/fstab и смонтировал по ней том в /mnt/lab-data. Ночные отчёты report-0915.txt и report-0916.txt остались под томом. Перенеси их на том, чтобы служба видела их в /mnt/lab-data рядом с archive, и подключи том обратно по таблице.
Цели · 0 из 2
- Достать ночные отчёты из-под тома ещё не выполнена
- Подключить том и положить отчёты на него ещё не выполнена