Переваги файлової системи без розділів

39

Я наткнувся на щось пару тижнів тому, чого я ніколи не бачив: Файлова система (ext3, я вважаю) встановлена на запам'ятовуючий пристрій без розділу. По суті /dev/sdb була вся файлова система. Я знаю, що багато файлових систем можна розширити на порожній простір, тому це дозволяє розширювати, не маючи стосунків з LVM чи яким-небудь іншим диспетчером томів, але чи є інші переваги для налаштування сховища таким чином?

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

filesystems partition lvm

— sysadmin1138
джерело

Oracle VM робить це теж для "локального зберігання".

— Нілс

3

Я пропустив це питання і почав нове, яке охоплює ту саму основу: unix.stackexchange.com/q/52389/4801 . Це питання закрито, але деякі відповіді там можуть бути корисними читачам цього запитання, і вони можуть бути об'єднані тут.

— сумнівним

1

... та ще один на unix.stackexchange.com/questions/206141/…

— derobert

Працює , але призводить до проблем , які в кінцевому підсумку витрачати час , як показано тут - access.redhat.com/documentation/en-us/red_hat_enterprise_linux / ... .

— slm

24

Pro: ви не витрачаєте один сектор диска на таблицю розділів. (Так.)

Pro: диск можна використовувати в операційній системі, яка не підтримує розділи в стилі ПК. (Як і ви збираєтесь використовувати його.)

Кон: це незвично і може бентежити співавтомати. (Побачити?)

Зрозуміло: якщо ви встановите іншу операційну систему, може здатися, що на диску міститься сміття, і полегшити його випадкове перезапис, вибравши неправильний диск - тоді як операційні системи, як правило, залишають окремі розділи, тип яких вони не розуміють.

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

Висновок: це працює, але це не дуже гарна ідея.

— Жил "ТАК - перестань бути злим"
джерело

2

Плутанина, ах! Наразі мій внутрішній лічильник схиляється до "неправильної спроби оптимізації".

— sysadmin1138

6

інший мінус: ускладнює згодом розділення розділу на дві частини.

— Кім

3

Натрапив на цей суперпопулярний Q&A, який має кілька хороших прикладів використання hexdumpта odякі дуже конкретно показують, що відбувається з налаштуваннями /dev/sdaпроти .. /dev/sda1

— slm

4

Розширити гучність на цілому диску трохи простіше, оскільки спочатку не потрібно розширювати розділ.

— psusi

2

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

— Грем Ніколлс

18

Не впевнений у тому, як це застосовуватиметься до Linux, але з нативним ZFS, одна з причин рекомендується створювати пули на цілих дисках, а не на розділах. У першому випадку кеш запису диска може бути ввімкнено.

Тут також згадується кілька інших причин:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

Висновок: він працює і може бути хорошою ідеєю залежно від файлової системи.

— jlliagre
джерело

Добре знати. У цьому конкретному випадку це було у хмарі! тому зберігання досить сильно абстрагується часом, коли він приходить до налаштування системи.

— sysadmin1138

1

Що, на землю, має кеш запису на диск, чи використовується таблиця розділів чи ні?

— psusi

3

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

— jlliagre

4

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

— jlliagre

1

@psusi Незалежно від того, чи буде fsync промивати кеш диска чи ні, це виглядає залежно від файлової системи.

— jlliagre

16

Я бачу справжню користь, коли це робиться у віртуальному середовищі. Оскільки наші VMDK зберігаються в нашій NAS, ми можемо їх динамічно вирощувати.

Якщо ми використовуємо розділи, нам або потрібно використовувати LVM (і накладні витрати, пов'язані з ним), і ланцюг розділів разом, або нам потрібно зняти хост (або файлову систему, якщо він не використовується), щоб використовувати щось на кшталт gparted.

Однак якщо ви використовуєте весь диск замість розділу, ви можете примусити пересканувати на своїх SCSI дисках і використовувати resize2fs для вирощування файлової системи під час роботи в режимі он-лайн (і в користуванні!).

— Нік Гаспарович
джерело

Влучне зауваження! З віртуальними дисками (як можна створювати, видаляти та змінювати їх розмір за потребою) розділи здаються непотрібним шаром.

— пабук

11

Розміщення файлової системи на дисковому пристрої без створення жодного розділу не така вже й рідкість.

Переваги:

коли ви хочете використовувати весь простір так чи інакше, вам не доведеться витрачати свій час на якийсь інструмент розділення
Вам не доведеться турбуватися про несумісність "стандартного" формату розділів (btw, який формат розділів є стандартним, DOS-формат, BSD-формат?), наприклад формат DOS-розділів дозволяє використовувати лише розділи до 2 ТБ при використанні Логічні сектори 512 байтів!
вам не доведеться турбуватися про проблеми з вирівнюванням, викликані розділами, на дисках з (на даний момент) незвичними розмірами сектору (наприклад, 4 к) - впевнені, що поточні дистрибутиви повинні доставляти інструменти для розділення, які правильно вирівнюють різні розміри сектору

Можливість змінити розмір файлової системи на необробленому пристрої - не вагома причина. Простір, який ви заощадите таким чином, ви не можете використовувати для інших речей. Таким чином, ви можете просто безпосередньо створити файлову систему на цілому пристрої.

— maxschlepzig
джерело

2

Відповідь, яка не була зазначена в списку, полягає в тому, що якщо ви не створюєте розділ, вам не доведеться чекати, коли ядро виявить його, що може бути тільки після перезавантаження.

Одним із випадків використання може бути обсяг EC2 EBS, який ви додаєте до вузла і хочете ініціалізувати під час першого завантаження.

Якщо ваш процес ініціалізації створює розділ, ви ризикуєте перезавантажити ядро, щоб побачити новостворений розділ. Зазвичай ви бачите повідомлення типу:

Помилка: Помилка інформування ядра про зміни в розділі / dev / xvde1 - Пристрій або ресурс зайнятий. Це означає, що Linux не буде знати про будь-які зміни, які ви внесли в / dev / xvde1, доки не перезавантажитеся, тому вам не слід встановлювати його або використовувати його будь-яким чином перед перезавантаженням.

У цьому випадку процес ініціалізації повинен був виконати перезавантаження, а потім продовжити додавання файлової системи до новоствореного розділу.

Якщо ви знаєте, що вам знадобиться лише один розділ, ви можете також пропустити його, тим самим не ризикуючи вимагати перезавантаження.

— lloesche
джерело