1. вступ
2. Виправлення замовчувань «кореня»
3. Файлові системи «постійної готовності»
4. застосування змін
5. залучення tmpfs

Олексій Федорчук

Інсталятор з комплекту Systemback, при всіх своїх численних достоїнствах, володіє одним вродженим недоліком: при установці системи він не дозволяє задіяти автоматичне підключення довільного розділу, що несе довільну файлову систему, в довільну точку монтування. І, тим більше, не дозволяє подмонтировать існуючу файлову систему без її переформатування і, отже, без втрати даних.

вступ

Втім, зазначений вище недолік - відносний. І, як часто трапляється, іноді переходить в гідність. Особливо якщо згадати, з одного боку, скільки гірких сліз було пролито поколіннями користувачів по безцільно загубленим даними, викликаним банальним неувагою до галочці, розпорядчої форматувати несучу їх файлову систему. А з іншого - якщо знати, що забезпечення такого в спокійній пост-інсталяційної, обстановці - процедура зовсім не важка. Але оскільки виявляється, що нині процедура ця щільно забута, її опису і буде присвячений цей нарис.

Умови автоматичного монтування файлових систем при старті машини описуються в одному з ключових конфігураційних файлів будь-якій UNIX-подібної системи, в тому числі і будь-якого Linux'а. Файл цей - / etc / fstab, і являє собою дуже просту базу даних, що містить такі поля, розділені пробілами або табуляцією:

• ім'я файлу пристрою, відповідного монтовані розділу, або інший його ідентифікатор, підтримуваний системою іменування;
• точка монтування, тобто ім'я каталогу в файлової ієрархії, в який буде включена вмонтовується файлова система;
• тип файлової системи з числа підтримуваних ядром Linux;
• різні додаткові опції монтування;
• умови створення дампа файлової системи і її перевірки.

Відразу після установки Cintu за допомогою інсталятора з Systemback файл / etc / fstab виглядає наступним чином:

# <File system> <mount point> <type> <options> <dump> <pass> # / / dev / sda1 UUID = [бла-бла] / ext4 errors = remount-ro 0 1

Тут UUID (Universally Unique IDentifier) ​​- один з видів підтримуваних ідентифікаторів пристроїв, в тому числі блочних (тобто дисків і їх розділів), значенням якого є зубодробильна послідовно алфавітно-цифрових символів. Наприклад, у мене він виглядає так:

UUID = bf6a6e6e-9678-4a21-ab48-a44d51bc0a87

Символ /, як неважко здогадатися - точка монтування, в даному випадку це корінь файлової ієрархії, а ext4 - тип файлової системи. Значення в поле опцій монтування наказують в разі помилок перемонтувати кореневу файлову систему в режимі тільки для читання, в інших полях записи не створювати дам її, але здійснювати перевірку в першу чергу (це - значення за замовчуванням для кореневої файлової системи).

Так що, якщо потрібно підключити існуючий розділ з будь-якої Linux'овой файлової системою і даними на ній, досить створити ще одну запис у файлі / etc / fstab за образом і подобою існуючої.

Виправлення замовчувань «кореня»

Перший крок у вирішенні поставленого завдання - відкриття з правами адміністратора потрібного нам файлу. Наприклад, в терміналі це можна зробити так:

$ Sudo nano / etc / fstab

А в графічному режимі - трохи інакше: комбінацією клавіш Alt + F2 викликати командний рядок мінітермінала і набрати в ній

gksu leafpad / etc / fstab

Чому в різних випадках для набуття прав адміністратора використовуються різні команди - буде сказано згодом. Поки ж важливо, що в обох випадках буде потрібно введення пароля користувача, після чого необхідний файл буде відкритий - або в редакторі Nano у вікні терміналу, або у власному вікні редактора Leafpad. І залишається тільки додати в нього запис з усіма заповненими полями.

Однак перш можна зробити з наявної за замовчуванням записом пару маніпуляцій. Наприклад, я завжди додаю в список опцій її монтування таку, як noatime, яка забороняє оновлювати час останнього доступу (так зване Access Time) до файлів і каталогів. На настільній машині воно не потрібно (майже?) Ніколи, але злегка знижує швидкодію і, ймовірно, трохи підвищує знос накопичувачів, особливо SSD.

Тут треба зробити кілька зауважень. По-перше, часто можна наштовхнутися на пропозицію додати також опцію nodiratime - як неважко здогадатися, вона забороняє оновлення Access Time для каталогів (і тільки для них). Однак при використанні опції noatime це робити не тільки не обов'язково, але і не потрібно: каталоги є одним з типів файлів, а тому дія noatime поширюється і на них.

По-друге, настільки ж часто пропозиція замість noatime використовувати опцію relatime, як більш «прогресивну»: при ній Access Time оновлюється тільки в тому випадку, якщо оновилися час модифікації файлу або його статусу. У десктопних умовах це, знову ж таки, надмірність: реально знання часу доступу необхідно лише при використанні деяких програм (наприклад, консольних поштових клієнтів), в нинішньому житті «настільного применителей» застосовуються досить рідко. А ось зниження продуктивності дискових операцій і зносу накопичувачів вона сприяє, хоча і не настільки «добре», як умолчальне опція atime, що повністю гаситься нашої noatime.

Нарешті, по-третє: в ядрі Linux, починаючи з версії 4.0, підтримується опція монтування lazytime, яка також забезпечує доступ до Access Time в необхідних випадках (тобто при зміні даних файлу або його атрибутів), але робить це не настільки «накладно» , як relatime. Однак, подібно до останньої, і вона потрібна лише рідкісних ситуаціях. І ті, кому вона реально необхідна, самі знаю, в яких.

Для кореневого (та й будь-якого іншого) розділу на SSD корисною вважається опція discard - звичайно, для тих файлових систем, в яких вона підтримується (з нативних Linux'ових це, крім ext4, ще й btrfs). Вдаватися в обговорення її реальної потрібності я тут не буду, при сучасному розвитку друкарської справи контролерів SSD-накопичувачів це питання спірне. Однак шкоди від неї, начебто, немає, тоді як користь - можлива, так що додати її - не гріх. В результаті редагована рядок придбає вигляд:

UUID = [бла-бла] / ext4 noatime, discard, errors = remount-ro 0 1

На якому можна і заспокоїтися.

Файлові системи «постійної готовності»

Ну а тепер - власне про автоматичне монтування розділу, що несе файлову систему з одними даними. Розглянемо модельну, але вельми поширену, ситуацію: є єдиний диск з двома розділами, / dev / sda1 і / dev / sda2. На перший засобами Systemback'а була встановлена ​​Cintu (або будь-який інший дистрибутив Linux, який використовує той же комплект для створення образів і інсталяції з них системи, наприклад, Matuntu ), На другому є файлова система з одними даними, постійний доступ необхідний конче.

Власне, деяких коментарів вимагає тільки перше поле - ім'я або ідентифікатор розділу. Тут можна використовувати так зване ім'я першого рівня - тобто, в нашому прикладі, / dev / sda2. Однак в Ubuntu і всіх її похідних прийнято, як уже було сказано, використання UUID. Не вдаючись в обговорення питання, добре це чи погано (він лежить далеко за рамками поставленого завдання і детально розглянуто в відповідному нарисі ), Просто підемо традиції. Для чого потрібно цей самий UUID визначити.

Як завжди, зробити це можна більш ніж одним способом. Перший - використання спеціально призначеної для цього команди:

$ Sudo blkid / dev / sda2

яка виведе щось на зразок цього:

/ Dev / sda2: UUID = "0bbc88c4-8d12-4065-9483-6a8029f3257c" TYPE = "ext4" PARTUUID = "000c5e9f-02"

Легко здогадатися, що саме значення UUID (але без лапок!) І потрібно вписати в перше поле потрібного рядка.

Другий спосіб не вимагає ні запам'ятовування спеціальної команди, ні навіть прав адміністратора (необхідних для виконання blkid). Бо все UUID'и - не більше ніж символічні посилання на імена блокових пристроїв першого рівня, і їх можна просомтреть безпосередньо:

$ Ls / dev / disk / by-uuid

А за допомогою команди

$ Ls -l / dev / disk / by-uuid | grep sda2

легко визначити, який з UUID'ов відповідає потрібному нам файлу пристрою:

lrwxrwxrwx 1 root root 10 трав 12 17:17 0bbc88c4-8d12-4065-9483-6a8029f3257c -> ../../sda2

У друге поле вписується ім'я каталогу (з вказівкою повного шляху), в який буде монтуватися файлова система - наприклад, я для зберігання призначених для користувача даних, доступних з усіх моїх систем (іноді вельми численних), використовую каталог / home / data (чому - окреме питання ). Який, зрозуміло, повинен бути створений заздалегідь:

$ Sudo mkdir / home / data

Третє поле - тип файлової системи, в якій був колись відформатований розділ - в моєму випадку це також ext4. Однак ніхто не забороняє під'єднати тим же чином розділ з будь-якою іншою раніше створеної файлової системою, наприклад, xfs або reiserfs, вписавши туди відповідне ім'я.

В поле опцій монтування досить обмежитися значеннями noatime, discard. Втім, останнє, як вже говорилося, застосовується тільки для SSD-накопичувачів, а також не підтримується файловими системами XFS і ReiserFS.

Нарешті, для двох останніх полів є сенс проставити умолчальне нулі, хоча для поля pass іноді рекомендується «двійка». Чому - знову ж обговорювати не буду, але реально применителей зазвичай ні найменшої різниці не помітить. Так що підсумковий вид нового запису в / etc / fstab буде приблизно таким:

UUID = [бла-бла] / home / data ext4 noatime, discard 0 0

Тим же самим чином можна забезпечити і монтування будь-якого іншого розділу, наприклад, з колекцією всякої парнуху мультимедии - ось тут доцільно використовувати XFS:

UUID = [інше-бла-бла] / home / media xfs noatime 0 0

В принципі, точно так же можна забезпечити і автоматичне монтування носіїв з будь-якої «чужої» файлової системою, на кшталт NTFS, але практично це мені не знадобилося ні разу в житті.

застосування змін

Зміни, зроблені в / etc / fstab, вступлять в силу після перезавантаження системи. Або після команди

$ Sudo mount -a

Попередньо, зрозуміло, не забувши створити всі прописані в / etc / fstab точки монтування - и наведеному прикладі командою

$ Sudo mkdir / home / media

Уважний читач звернув увагу, що вище точки монтування в каталозі / home створювалися від імені адміністратора, тобто їх власником є ​​користувач root. Однак каталоги і файли змонтованих в них файлових систем успадкують атрибути приналежності і доступу, отримані при їх створенні. Так що проблем з доступом до них після перемонтування не буде - принаймні, для того користувача, чий акаунт створювався при інсталяції системи. Чому - буде з часом обговорюватися окремо.

залучення tmpfs

Нарешті, можливо, корисною виявиться ще одна, опциональная, запис в / etc / fstab:

tmpfs / tmp tmpfs noatime 0 0

Вона монтує в каталог / tmp, призначений для зберігання тимчасових файлів, файлової системи в оперативній пам'яті, яка так і називається - tmpfs. Розмір її за замовчуванням дорівнює половині готівкової пам'яті, проте його можна задати і явно, більшим чи меншим, вказавши це в якості опції монтування size = ## (в будь-яких * байтах або відсотках RAM). У будь-якому випадку, оперативна пам'ять не резервується під tmpfs, а задіюється при необхідності. Крім того, в цілях безпеки для tmpfs рекомендуються опції, які забороняють виконання в ній файлів, присвоєння їм біта suid'ності і розміщення файлів пристроїв. Так що «по науці» наведена вище рядок повинен виглядати приблизно так:

tmpfs / tmp tmpfs noatime, noexec, nodev, nosuid, size = ## g 0 0

Після цього для задіяння tmpfs бажана перезавантаження системи: за час сеансу в / tmp, ще розташованої на диску, накопичується достатня кількість «мотлоху», який теоретично повинен зникнути при рестарт.

Повинен попередити, що використання tmpfs для монтування в каталог / tmp вважається досить спірним. З одного боку, вигоди такого рішення очевидні: підвищення швидкодії (хоча нині й практично непомітне), зниження зносу накопичувача, гарантія очищення / tmp від «продуктів життєдіяльності» при рестарт системи. Недоліків же його два. По-перше, останнім часом воно дуже не рекомендується розробниками більшості дистрибутивів. Хоча виразних пояснень такої «нерекомендабельності» в загальному випадку я не знайшов, за винятком невиразних вказівок на якусь «можливу нестабільність». З якої, втім, теж не стикався.

Так що якщо для вас, як і для автора цих рядків, деякі (хоча, повторюю, нині і не дуже значні) переваги використання tmpfs важливіше проходження догмам майнтайнеров - не бійтеся, нічого страшного не станеться. На крайняк, якщо горезвісна нестабільність себе якось підступно проявить - ліквідувати наведену вище рядок труднощів не складе.

Автор цих рядків завжди вважав, що, всупереч поширеній думці колись знаменитої Ніни Андрєєвої, немає таких принципів (і, тим більше, догм), які не заслуговували б того, щоб ними поступилися в інтересах справи. І тому завжди включав монтування tmpfs в каталог / tmp описаним тільки що способом. За винятком тих випадків, коли банально забував це зробити. Як, наприклад, забув при первинній настройці системи, в якій складає ці рядки - і зробив це тільки зараз. Так що можливість легко забути про таку хорошу штуку, як tmpfs - її другий (і, на мій погляд, головний) недолік ...