Продам перегородку мені


46

Я часто замислювався, чому існує така пристрасть до розділення дисків, особливо на ОС Unixy (/ usr, / var, та ін.). Здається, це не є загальною темою для інсталяцій Windows.

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

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

Майже 100% проблем, з якими я стикався зі зберіганням диска, - це фізичний збій диска. Чи можна стверджувати, що розділення може потенційно прискорити збій апаратури через обмолот диска при переміщенні чи копіюванні даних з одного розділу в інший на одному диску?

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


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

Відповіді:


41
  • Швидше fsck. Скажімо, ваша система виходить з ладу, чомусь і коли вона перезавантажується, їй потрібно запустити fsck. З дійсно великим розділом, який fsck може зайняти назавжди, і нічого в системі не буде працювати, поки не буде виконано fsck всієї системи. Якщо ви розділите систему, щоб кореневий розділ був досить малим, можливо, вам вдасться отримати систему та деякі основні сервіси, які працюють, поки ви будете чекати завершення fsck більшого обсягу.
    • якщо у вашій системі є невеликі накопичувачі або є лише одна служба в системі, це може не мати особливого значення.
    • З файловими системами, що переводяться в журнал, це може не мати значення більшої частини часу, але іноді навіть із файловою системою, що перебуває в журналі, вам доведеться запустити повний fsck.
  • Покращена безпека, оскільки ви можете встановити Fs лише для читання.
    • Наприклад, нікому не потрібно писати в / usr під час звичайного використання. То чому б не просто встановити файлову систему, щоб вона була лише для читання. Наявність файлових систем лише для читання, коли їх не потрібно писати, щоб запобігти деяким хитним сценаріям атаки, а також може запобігти знищенню речей, коли ви теж не маєте на увазі.
    • Це може ускладнити підтримку системи, оскільки вам потрібно буде перезаписати її як читання-запис, коли потрібно застосувати оновлення.
  • Покращена продуктивність, функціональність для конкретної послуги / використання.
    • Деякі файлові системи є більш підходящими для конкретних служб / додатків, або вони дозволяють налаштувати файлову систему так, щоб вона працювала краще в деяких випадках. Можливо, у вас є файлова система з великою кількістю невеликих файлів, і вам потрібно більше вкладень. Або, можливо, вам потрібно зберегти кілька великих файлів, віртуальних образів диска.

Я не думаю, що налаштування багатьох розділів - це те, що ви повинні робити для кожної системи. Особисто на більшості моїх серверів Linux я просто налаштовую один великий розділ. Оскільки більшість моїх систем мають невеликі накопичувачі та мають єдину ціль і виконують певну роль у інфраструктурі (dns, dhcp, брандмауер, маршрутизатор тощо). На своїх файлових серверах я встановлюю розділи для відділення даних від системи.

Чи можна стверджувати, що розділення може потенційно прискорити збій апаратури через обмолот диска при переміщенні чи копіюванні даних з одного розділу в інший на одному диску?

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


9
+1 Як безпека, так і готовність до катастроф виконуються пошарово. Мені подобається думати про перегородки, схожі на перегородки на кораблі. Вони існують так, що якщо щось катастрофічне трапиться в одному сегменті корабля, судно в цілому не обов'язково загрожує. Тож, коли трапляється пошкодження файлової системи, шкода дещо міститься. Так само з точки зору безпеки, якщо / будинки встановлені як noexec, це може запобігти певним видам атак, якщо, наприклад, обліковий запис користувачів порушений слабким паролем.
3вплив

1
Відомі подвиги, що працюють лише на перегородках, встановлених noexec або ro. реальна безпека не спрямована декомпозицией, але секціонування може допомогти в збиток обмеження (. ЧФР реєструє повені нападу, наприклад)
drAlberT

19

Однією з причин збереження / home / loperate є те, що ви можете перевстановити операційну систему і ніколи не турбуватися про втрату даних користувача. Крім того, існує велика безпека в монтажі всього, або лише для читання, або noexec. Якщо користувачі не можуть запустити код ніде, щоб вони могли написати код, це один вектор атаки менше.

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


розділення / додому звучить більше як річ на робочому столі. Дані на серверах часто є в якомусь іншому місці, наприклад / var / www, / srv. Я б зауважив, що ваша ідея повинна більше стосуватись розділення даних користувача, де б вони не зберігалися, а не лише, якщо вони є в / вдома.
Zoredache

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

Якщо у вас є значна кількість машин, часто / home - це кріплення NFS з файлового сервера, який логічно має / home на своєму розділі, через вищезазначені проблеми.
Метт Сіммонс

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

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

13
  • Спрощення резервного копіювання

Ви можете робити резервні копії (через dumpfs або подібні) речей, які ви хочете, а не речей, яких ви не маєте. dump (1) - краща система резервного копіювання, ніж tar (1).

  • Заповнення перегородок

Це теж аргумент для розділення. Користувачі, які заповнюють своїх хомедірів, не руйнують сервер, не знімають веб-сервер, не підтримують журнали, не входять у систему і т.д.

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


9

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


1
Я можу розраховувати однією рукою за свою 15-річну кар’єру (що? Скажіть, це не так!) Кар'єру, скільки разів я втрачав систему, тому що файл журналу, який вибіг (чи що завгодно), збив машину. З іншого боку, я можу порахувати, з однієї сторони, кількість разів до цього року, коли я був змушений, тому що хтось вирішив / var ніколи не повинен бути більшим за 1 Гб і помилявся, що залишило мене дивитись на '00 безкоштовно Гб в / opt, все це, можливо, також було на Місяці за все хороше, що мені робить. (Я проти поділу. :)
Девід Макінтош

Я погоджуюся з Девідом, маючи абсолютно однаковий досвід роботи з ОС Linux та Windows. Якщо немає переважних причин робити інакше кожен диск (або рейдовий масив) отримує один розділ.
John Gardeniers

Що ж, цього тижня це остаточно відбулося в системі Windows. McAfee випустив велике оновлення. У нас було близько 5-10 систем, які не сподобалися. Антивірус спробує встановити, створити файл журналу 35 МБ та спробувати ще раз. Через півтора тисячі разів у мене було 0 КБ безкоштовно та система, до якої не вдалося ввійти.
Skaughty

8

Усі аргументи, які висуває Зоредаш, є справедливими; можна трохи посперечатися з деталями (мати машину швидше, щоб ви могли робити інші речі, тоді як fsck'ing інших файлових систем не принесе вам великої користі, якщо причина системи, що існує в першу чергу, в інших файлових системах) ; проте всі вони трохи виправдання після факту.

У справді старошкільні часи у вас не було файлових систем на окремих розділах - ви мали їх на окремих дисках, тому що диски справді були маленькими. Подумайте, 10 Мб. (1) Отже, у вас був крихітний / розділ, диск / var, диск / usr, диск / tmp та / домашній диск. Якщо вам потрібно було більше місця, ви купили ще один диск.

Тоді "великі" 50 Мб диски почали коштувати менше, ніж місячна програма, і раптом з'явилася можливість помістити всю систему на один диск з корисною кількістю простору користувача.

Тим не менше, розміри дисків були невеликими порівняно з тим, що комп'ютер міг генерувати, ізолюючи / var та / opt та / home, щоб заповнення одного не збило комп'ютер, все ще була хорошою ідеєю.

Сьогодні, в умовах підприємства, я не розділяю ОС. Дані відключаються, особливо якщо вони створені користувачем; але часто це відбувається тому, що це на високошвидкісних та / або надлишкових дискових масивах. Однак / var та / usr всі живуть у тому ж розділі, що і /.

У домашньому середовищі те саме - / home, ймовірно, має бути на окремому диску / масиві, щоб можна було встановити / оновити / зламати / виправити будь-які смаки ОС.

Причина цього полягає в тому, що незалежно від того, наскільки великими ви здогадуєтесь / var або / usr або будь-яке інше дерево, ви отримаєте помилкову помилку, або будете смішно перевантажуватись. Один з моїх старих шкільних колег присягає розділитись, і я завжди отримую від нього горе, коли він закінчується сидіти через 180-денний fsck у створеній мені системі. Але я можу розраховувати однією рукою протягом усієї своєї кар’єри, скільки разів щось заповнювалося / і збивало систему, в той час як я можу рахувати однією рукою кількість разів до цього року, що я дивився на систему, де хтось вирішив / var ніколи не повинен бути більше, ніж (скажімо) 1 Гб, і помилявся, залишаючи мене, дивлячись на повний / var і '00 вільних ГБ в інших місцях системи, і все це, можливо, також було на Місяці для всіх добро, яке вони мені роблять.

У сучасному світі великих дисків я не бачу, що існує якась реальна причина розділити дерево ОС. Дані користувачів, так. Але окремі розділи для / var та / usr та / var / spool тощо тощо тощо? Немає.


(1) = і я знаю, лише вибравши цей розмір, я збираюсь когось у коментарях сказати 10 Мб? Розкіш. Чому наші диски були просто ...


Насправді 10 Мб був розміром диска, коли я колись чув когось "XXX FooBytes: більше пам'яті, ніж мені коли-небудь знадобиться!". Хоча я і молодий, так це було близько 1982 року. Інші значення - 40 МБ, 320 МБ, 2,5 ГБ, 40 ГБ, ... дані розширюються, щоб заповнити наявний сховище.
dmckee

5

У відповідь на:

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

На машині Linux для запобігання цього використовується LVM (логічне управління томом). Більшість файлових систем дозволяють змінювати розміри (деякі навіть в Інтернеті). Я створюю різні розділи для різних цілей і відформатую їх у різні файлові системи (тобто: xfs для великих файлів завантаження, які я можу швидко видалити). Потрібно більше місця? Змонтуйте новий накопичувач, перемістіть його до нього, а потім змонтуйте там, де раніше були дані. Це абсолютно безшовно для користувачів та програм.

За допомогою LVM ви можете додати диски або розділи до групи томів, а потім створити логічні томи в цій групі. Якщо ви залишите вільний простір у групі томів, ви можете виростити розділи, що заповнюються. Якщо файлова система підтримує її (ext3, ext4, reiserfs), ви можете зменшити розділ, який ви виділили.

Наприклад: зробити завантажувальний розділ на / dev / sda1 зробити другий (неформатований) розділ / dev / sda2

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

Коли вам потрібно більше місця на / завантаження (тоді як файлова система змонтована):

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

А тепер у вас є розділ для завантаження на 150 ГБ. Подібно додому. Насправді я просто змінив розмір "перегородки" ext4 lvm сьогодні. З іншого боку, логічні томи насправді не є розділами, і те, що ви говорите про те, що розділи мають неправильний розмір з моїм особистим досвідом (більше клопоту, ніж вони варті).


4

Традиційна схема розбиття Unix - це, безумовно, стара шкільна практика, не така корисна, як раніше. Ще в той час, коли час роботи Unix вимірювались роками, і у вас було десятки сотень користувачів, які обминалися з оболонками, корисним способом захисту системи був монтаж / usr як лише для читання. Тепер перевстановлення файлових систем для виправлення здається більш трудомістким і не таким корисним.

У моєму університеті ще в добрі старі часи кластери Unix мали файлові системи лише для читання зі стандартними інструментами unix, а додаткові додатки були в / usr / local, що являло собою файлову систему NFS, а пізніше файлову систему AFS. Частиною цього було зручність ... хто хотів перекомпілювати програмне забезпечення на десятках ящиків у кластері, коли ви могли запускати програми через швидкісну, 4 Мбіт або 10 Мб мережу? Сьогодні, з гідними менеджерами пакунків та безліччю дешевих дисків, справа не така вже й велика.

Я думаю, що думові процеси почали змінюватися для мене на скриньках Sun із Veritas Volume Manager ще близько 1999 року, що значно знизило поріг болю при переміщенні дисків.

Сьогодні, коли я думаю про розподіл, я думаю про захист даних та ефективність. Ілюстративний приклад:

  • SAN 1 рівня дуже швидкий, дуже доступний (5 9-х), тиражується та дуже дорогий. Критичні Бази даних або журнали транзакцій живуть там.
  • 2-й рівень SAN - швидкий, доступний (4 9-х), дорогий. Тут зберігаються програми або дані нижчого пріоритету.
  • 3 рівень SAN доступний (4 9-х), дешево. Речі, які там не чутливі до продуктивності.

Ці міркування стосуються і Windows. У нас є сервер SCCM, який управляє близько 40 тис. Клієнтів. База даних та журнали знаходяться на мега-доларовому диску IBM DS8000. Програмні пакети є на EMC Celerra з великими повільними дисками SATA, які коштують на 60% менше за ГБ.


2

Я розумію, що це питання не стосується ОС, правда?

У Windows я схильний надавати всім моїм машинам якомога менше розділів, але не менше двох - SYSTEM і DATA. Якщо машина має два фізичні диски, то один (менший) буде СИСТЕМА, інший ДАННІ. Якщо є лише один диск, я розділив його на два розділи.

Причина тому лише одна - коли мені потрібно перевстановити машину (і буде такий час), мені не доведеться турбуватися про вміст розділу SYSTEM - я просто створюю повний формат на ньому та чиста установка. Це, звичайно, означає, що мої Документи (а краще і Desktop теж) повинні бути відображені в папці DATA, але це легко зробити, особливо на Vista та пізніших версіях.

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


Це ще більше застосовується, коли це робиться на серверах.
SpaceManSpiff

2

(Передбачається , що один великий диск доступний) , я поставив homeі varна окремі розділи для управління «з - під контролю [користувач | лог - файл] заповнюючи весь простір» проблеми і можливості легкої модернізації операційної системи , у цілому будинку, але залишити відпочивати разом.

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


2

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

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

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

... тепер, усе, що говориться, нам далеко не дні, коли кожен користувач отримує свою маленьку квоту 20 Мб на загальній машині. Деякі старі звички не мають сенсу, - але коли у вас є процес, виходить з розуму і заливаєте / var, який, у свою чергу, заповнює /, і все перестає зупинятися, не все так погано захищати на виробничих машинах .

Для дому у мене є розділи, але це просто для полегшення управління встановленими ОС.


1

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

У корпоративному середовищі я ніколи не чув переконливого аргументу щодо розділення.


1

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

Не змішуйте це з помилкою апаратного забезпечення - вони повинні вирішуватися за рахунок надмірності обладнання (RAID)

Сказавши це, файлові системи в ці дні виходять з ладу рідше - ом навіть роблять перевірку цілісності в Інтернеті (наприклад, ZFS). Тож, сподіваємось, офлайн fsck піде в якийсь момент ...

З іншого боку, перевиконання цього означає лише більше роботи (для вас та вашої команди) наприкінці - просто робіть це в міру та коли це має сенс ...

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.