Ответ
Файл /etc/fstab (File System Table) содержит статическую информацию о файловых системах, которые должны монтироваться автоматически при загрузке системы или вручную командой mount. Каждая запись состоит из шести полей:
- Устройство — идентификатор раздела (путь
/dev/sda1, UUID или метка LABEL). - Точка монтирования — каталог, куда будет смонтирована ФС.
- Тип файловой системы — например,
ext4,xfs,ntfs,swap. - Опции монтирования — разделенные запятыми параметры (
defaults,noatime,ro,noexec). - Dump — флаг для утилиты
dump(0 — не делать резервную копию). - Fsck order — порядок проверки ФС утилитой
fsck(0 — не проверять, 1 — корневая ФС, 2 — остальные).
Пример записи для монтирования по UUID:
# <device> <mount point> <type> <options> <dump> <fsck>
UUID=550e8400-e29b-41d4-a716-446655440000 /data ext4 defaults,noatime 0 2Практическое использование в DevOps: Этот файл критичен для автоматизации развертывания. Мы используем инструменты вроде Ansible для его управления, чтобы гарантировать, что все необходимые тома (например, для логов или данных приложения) будут доступны после перезагрузки сервера.
Ответ 18+ 🔞
А, блядь, /etc/fstab! Ну это же классика, ёпта. Представь себе такую штуку — это как список обязательных дел для твоего компа, когда он просыпается. Типа «встал, умылся, привел себя в порядок — и сразу же примонтируй вот этот диск вот сюда, сука».
Смотри, как оно устроено, тут шесть пунктов, и если накосячить — будет тебе хиросима и нигерсраки при загрузке. Запомни, как «Отче наш».
Первое поле — кто монтируется. Раньше тупо писали /dev/sda1, но это, блядь, ненадёжно как мать его. Диск сегодня — sda1, а завтра после ребута станет sdb1, и всё, приехали, система не грузится. Поэтому все умные люди теперь используют UUID или LABEL. Это как паспорт у диска, уникальный, хуй с горы не свалится. Пишешь UUID=550e8400-e29b-41d4-a716-446655440000 и спишь спокойно.
Второе — куда монтируется. Ну, точка монтирования. Обычная папка. Хочешь, чтобы диск с фильмами был в /home/user/porno — пожалуйста. Главное, чтобы папка эта существовала, а то будет волнение ебать, система ругаться начнёт.
Третье — тип файловой системы. ext4, xfs, ntfs-3g, swap для свопа. Наврал тут — получишь ошибку монтирования, и будет тебе, чувак, терпения ноль ебать, пока разбираешься.
Четвёртое — опции, самая хитрая жопа. Тут можно указать, как именно общаться с диском. defaults — это обычно норм. Но если хочешь перформанса, добавишь noatime (чтобы не записывал время доступа к каждому файлу, лишняя нагрузка). Если диск для бэкапов и чтоб никто случайно не снёс — ro (read only). Для безопасности на сервере часто папку с временными файлами вешают с noexec, чтобы оттуда скрипты не запускались. Короче, поле для манёвров.
Пятое — про дамп. Это legacy такое, из древних времён. Ставь 0 и забей. Серьёзно, доверия ебать ноль к этому полю сейчас.
Шестое — порядок проверки fsck. Вот это важно! Для корневой файловой системы (/) ставишь 1. Для всех остальных, которые нужно проверять — 2. А для сетевых шары, swap или временных дисков — 0, чтобы не тратить время при загрузке.
Вот тебе пример, как это выглядит в жизни:
# <device> <mount point> <type> <options> <dump> <fsck>
UUID=550e8400-e29b-41d4-a716-446655440000 /data ext4 defaults,noatime 0 2Перевожу на русский: «Эй, система, как только встанешь, найди диск с вот таким паспортом (UUID) и примонтируй его в папку /data как ext4 с дефолтными настройками, но без записи времени доступа. Резервную копию не делай, но при проверке дисков зайдись им вторым по счёту».
А где это всё в DevOps применяется? Да везде, блядь! Это же основа основ стабильности. Когда ты разворачиваешь сто серверов через Ansible, тебе же неохота на каждом вручную mount тыкать? Вот ты и прописываешь в плейбуке: «На всех серверах, ребята, добавьте в /etc/fstab запись, что вот этот EBS-том в AWS надо примонтировать в /var/log/app, иначе логи наши пропадут после перезагрузки». И всё, автоматизация, красота. Главное — тесты написать, чтобы скрипт не добавил хуйни в файл, а то можно всю инфраструктуру положить, ядрёна вошь.