РазбиениеДиска
Материал из ALT Linux Wiki
Asy (обсуждение | вклад) (→Значение отдельных разделов) |
(→Примечания) |
||
(18 промежуточных версий не показаны.) | |||
Строка 6: | Строка 6: | ||
==Преамбула== | ==Преамбула== | ||
- | Существует мнение, что, на рабочей станции, вообще не следует делить HDD/SSD на разделы (исключая /boot/efi и, вероятно, swap), особенно, если рабочей станцией пользуется один пользователь. Плюс такого решения исключительно в том, что не придётся решать вопрос о выборе размеров разделов. В случае такого выбора | + | Существует мнение, что, на рабочей станции, вообще не следует делить HDD/SSD на разделы (исключая /boot/efi и, вероятно, swap), особенно, если рабочей станцией пользуется один пользователь. Плюс такого решения исключительно в том, что не придётся решать вопрос о выборе размеров разделов. В случае такого выбора всю статью можно не читать, но стоит ознакомиться с написанным про разделы '''{{path|/boot/efi}}''', '''{{path|swap}}''' и файловые системы btrfs и tmpfs. |
==Введение== | ==Введение== | ||
Строка 15: | Строка 15: | ||
* '''Повышение безопасности''' достигается за счёт различных опций монтирования, ограничивающих те или иные права для разных разделов. | * '''Повышение безопасности''' достигается за счёт различных опций монтирования, ограничивающих те или иные права для разных разделов. | ||
- | Следует понимать, что универсального решения не существует. Конечный результат зависит от назначения компьютера и особенностей его работы с наложенными предпочтениями и мнением того, кто устанавливал ОС. | + | <div style="display: inline; color: red;">Следует понимать, что универсального решения не существует. Конечный результат зависит от назначения компьютера и особенностей его работы с наложенными предпочтениями и мнением того, кто устанавливал ОС.</div> |
Есть мнение, что, по крайней мере, на тестовых машинах следует использовать [[LVM|LVM]], который позволяет, при соблюдении ряда правил, гибко манипулировать разделами без потери данных. Но это тема [[LVM|отдельной статьи]]. | Есть мнение, что, по крайней мере, на тестовых машинах следует использовать [[LVM|LVM]], который позволяет, при соблюдении ряда правил, гибко манипулировать разделами без потери данных. Но это тема [[LVM|отдельной статьи]]. | ||
- | ==Дисковая подкачка== | + | ==Загрузочный раздел GRUB для GPT== |
+ | |||
+ | На дисках размером больше 2 Гб мы вынуждены отказаться от MBR и использовать GPT. Но таблица разделов GPT не оставляет места для грубовского загрузчика второго этапа (GRUB boot stage two): в случае GRUB в первом секторе (512 байт) располагается "заглушка" MBR с единственной записью - разделом тип GPT, а во втором секторе диска - уже GPT. (В классическом MBR секторы со 2 по 63 оставались зарезервированными и GRUB stage 2 записывался туда.) Поэтому в GPT для загрузчика второго этапа предусмотрен специальный тип раздела - "BIOS Boot Partition", который в parted и GpartEd обозначается флагом "bios_grub". В старой GRUB Wiki была рекомендация сделать раздел не менее 31 кБ размером и назначить ему в parted флаг "bios_grub". Red Hat рекомендует делать такой раздел размером 1 Мб. | ||
+ | |||
+ | : Если планируете установить на диск GRUB на диск с таблицей разделов GPT, обязательно создайте на этом диске раздел размером от 31 кб до 1 Мб и задайте ему флаг bios_grub, после чего выполните команду <tt>grub-install /dev/диск</tt> (для проверки). | ||
+ | |||
+ | ==Дисковая подкачка (swap)== | ||
У swap есть несколько особенностей. | У swap есть несколько особенностей. | ||
# Если уж он используется, то доступ к нему должен быть максимально быстрый (а это значит либо начало, либо середина диска; для накопителей SSD место расположения, в плане скорости, значения не имеет). | # Если уж он используется, то доступ к нему должен быть максимально быстрый (а это значит либо начало, либо середина диска; для накопителей SSD место расположения, в плане скорости, значения не имеет). | ||
# Данные в swap не представляют никакой ценности после перезагрузки машины. | # Данные в swap не представляют никакой ценности после перезагрузки машины. | ||
- | # Если на компьютере (например, | + | # Если на компьютере (например, ноутбуке) планируется использовать режим гибернации, размер swap следует сделать несколько больше размера ОЗУ; если ОЗУ планируется наращивать в последствии, об этом лучше подумать заранее. |
+ | # Если для загрузки используете том RAID уровней больше 0, swap (тоже) располагайте на RAID-1, иначе при горячем отключении или поломке диска с размещённом на нём swap получите kernel panic. | ||
Наилучшим решением считается держать swap в начале диска, это поможет спасти информацию на диске при повреждении по каким-либо причинам информации в начале диска. Пример такой причины — опечатка при работе с разделами (указали вместо /dev/sda2 просто /dev/sda). | Наилучшим решением считается держать swap в начале диска, это поможет спасти информацию на диске при повреждении по каким-либо причинам информации в начале диска. Пример такой причины — опечатка при работе с разделами (указали вместо /dev/sda2 просто /dev/sda). | ||
Строка 30: | Строка 37: | ||
== Файловые системы == | == Файловые системы == | ||
- | === [ | + | === [[:ruwp:Ext2|ext2]] === |
<div class="NavFrame collapsed"> | <div class="NavFrame collapsed"> | ||
<div class="NavHead" align="left">Устаревшая файловая система.</div> | <div class="NavHead" align="left">Устаревшая файловая система.</div> | ||
Строка 42: | Строка 49: | ||
</div> | </div> | ||
- | === [ | + | === [[:ruwp:Ext3|ext3]] === |
<div class="NavFrame collapsed"> | <div class="NavFrame collapsed"> | ||
<div class="NavHead" align="left">Устаревшая файловая система.</div> | <div class="NavHead" align="left">Устаревшая файловая система.</div> | ||
Строка 56: | Строка 63: | ||
</div> | </div> | ||
- | === [ | + | === [[:ruwp:Ext4|ext4]] === |
Пришла на смену ext3, обладает заметно лучшей производительностью благодаря использованию extent-ов. | Пришла на смену ext3, обладает заметно лучшей производительностью благодаря использованию extent-ов. | ||
Применение: ныне самая универсальная файловая система под Linux, рекомендуется использовать её как файловую систему для самых ценных данных, так как она является наиболее надёжной из современных ФС. | Применение: ныне самая универсальная файловая система под Linux, рекомендуется использовать её как файловую систему для самых ценных данных, так как она является наиболее надёжной из современных ФС. | ||
- | === [ | + | === [[:ruwp:Btrfs|btrfs]] === |
Журналируемая файловая система нового поколения. Изначально разработана корпорацией Oracle, но, на текущий момент, в разработке участвуют RedHat и Fujitsu. ФС в стадии активной разработки, хотя базовый функционал считается уже стабильным. По скоростным характеристиками, по большей части, уступает остальным ФС, но значительно превосходит по возможностям (спорно относительно zfs). | Журналируемая файловая система нового поколения. Изначально разработана корпорацией Oracle, но, на текущий момент, в разработке участвуют RedHat и Fujitsu. ФС в стадии активной разработки, хотя базовый функционал считается уже стабильным. По скоростным характеристиками, по большей части, уступает остальным ФС, но значительно превосходит по возможностям (спорно относительно zfs). | ||
Строка 68: | Строка 75: | ||
б) из сложного - RAID средствами ФС (без mdadm), использование подразделов и т.п. | б) из сложного - RAID средствами ФС (без mdadm), использование подразделов и т.п. | ||
- | Примечание: использовать ядра младше 3.14 не рекомендуется; сложные конфигурации использовать без резервных копий не рекомендуется. | + | Примечание 1: использовать ядра младше 3.14 не рекомендуется; сложные конфигурации использовать без резервных копий не рекомендуется.<br> |
+ | Примечание 2: с учётом использования подразделов, вероятно, имеет право на жизнь совмещение подхода, описанного в преамбуле, с тем, что описано в статье, с учётом, разумеется, использования исключительно btrfs. | ||
- | === [ | + | === [[:ruwp:ZFS|zfs]] === |
Прогрессивная журналируемая файловая система, представленная Sun Microsystems в 2005 году в ОС OpenSolaris. Код ФС распространяется под лицензией CDDL, в силу этого не может быть включен в ядро Linux, однако модуль ФС присутствует во многих дистрибутивах Linux. Следует заметить, что Btrfs начинала разрабатываться, как конкурент ZFS, однако в 2010 году компания Sun Microsystems была куплена компанией Oracle. | Прогрессивная журналируемая файловая система, представленная Sun Microsystems в 2005 году в ОС OpenSolaris. Код ФС распространяется под лицензией CDDL, в силу этого не может быть включен в ядро Linux, однако модуль ФС присутствует во многих дистрибутивах Linux. Следует заметить, что Btrfs начинала разрабатываться, как конкурент ZFS, однако в 2010 году компания Sun Microsystems была куплена компанией Oracle. | ||
- | Ключевой особенностью ZFS считается контроль над физическими и логическими носителями. Зная, как именно расположены данные на дисках, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных. | + | Ключевой особенностью ZFS считается контроль над физическими и логическими носителями. Зная, как именно расположены данные на дисках, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных. Так же, как и btrfs, поддерживает разные уровни RAID и другие варианты объединения носителей в общее дисковое пространство. |
- | === [ | + | === [[:ruwp:ReiserFS|reiserfs]] === |
Устаревшая в пользу Reiser4, однако, в отличие от Reiser4, включенная в основное ядро Linux, журналируемая файловая система, которая отличалась от других с точки зрения администратора, в первую очередь, хорошей скоростью работы с каталогами, в которых большое количество маленьких файлов. Как и в ext3 в ветке {{pkg|2.6}}, в ней используются для поиска файла в каталоге B-tree и хэши. Кроме того она умеет компактно хранить хвосты от файлов для экономии места, обычно расходуемого впустую. | Устаревшая в пользу Reiser4, однако, в отличие от Reiser4, включенная в основное ядро Linux, журналируемая файловая система, которая отличалась от других с точки зрения администратора, в первую очередь, хорошей скоростью работы с каталогами, в которых большое количество маленьких файлов. Как и в ext3 в ветке {{pkg|2.6}}, в ней используются для поиска файла в каталоге B-tree и хэши. Кроме того она умеет компактно хранить хвосты от файлов для экономии места, обычно расходуемого впустую. | ||
- | + | Ещё одно преимущество - длина имени файла ограничена 3968 байтами в случае 4к блока (4096 байт блока минус 128 байт заголовков)<ref>[https://git.kernel.org/pub/scm/linux/kernel/git/jeffm/reiserfsprogs.git/tree/include/reiserfs_fs.h reiserfs_fs.h]</ref>, тогда как в большинстве файловых систем она ограничена 255 байтами. При использовании кодировки UTF-8 имя файла на русском языке занимает в байтах вдвое больше места (а, например, символы китайского языка кодируются 4 байтами). К сожалению, в библиотеке glibc длина имени файла и каталога также ограничена 255 байтами, поэтому для поддержки длинных имён файлов нужно также патчить glibc. См. [http://wiki.etersoft.ru/Linux/VLFN Ethersoft Wiki]. | |
+ | |||
+ | Применения: | ||
+ | * файловые системы с большим количеством маленьких файлов или с большим числом файлов в каталоге; | ||
+ | * в системе, собранной с модифицированным glibc — файловые системы с файлами с русскими именами и с именами на других национальных языках. | ||
- | === [ | + | === [[:ruwp:Reiser4|reiser4]] === |
- | Файловая система Reiser4 - наследница ReiserFS. На смену алгоритму [ | + | Файловая система Reiser4 - наследница ReiserFS. На смену алгоритму [[:ruwp:B%2B_дерево|B+-tree]] пришёл алгоритм [[:ruwp:Танцующее_дерево|dancing trees]]. Система была полностью подготовлена к включению в основное ядро Linux ещё в 2010 году, однако это не произошло. На текущий момент включение кода ФС в основное ядро не является приоритетом ввиду недостатка времени [http://habrahabr.ru/post/108629/ единственного оставшегося разработчика] (в этом интервью Эдуард Шишкин сказал несколько слов и о btrfs, но это интервью 2010-ого года). |
Применение: файловые системы с большим количеством маленьких файлов, или в которых большое количество файлов в каталоге. | Применение: файловые системы с большим количеством маленьких файлов, или в которых большое количество файлов в каталоге. | ||
Строка 87: | Строка 99: | ||
Примечание: в ALT Linux нет готовых ядер с поддержкой Reiser4. | Примечание: в ALT Linux нет готовых ядер с поддержкой Reiser4. | ||
- | === [ | + | === [[:ruwp:XFS|xfs]] === |
Разработка SGI, перенесённая в Linux. Присутствует в ядре, начиная с ядра {{pkg|2.4.25}}. Оптимизированная для быстрой работы с файлами большого размера (multimedia данных), обладающая великолепной надёжностью, имеющая поддержку ACL (полезно для файл-серверов с Windows-клиентами) и EA (до конца зачем они нужны понимают лишь бывшие пользователи OS/2, остальные смотрят на них с удивлением). | Разработка SGI, перенесённая в Linux. Присутствует в ядре, начиная с ядра {{pkg|2.4.25}}. Оптимизированная для быстрой работы с файлами большого размера (multimedia данных), обладающая великолепной надёжностью, имеющая поддержку ACL (полезно для файл-серверов с Windows-клиентами) и EA (до конца зачем они нужны понимают лишь бывшие пользователи OS/2, остальные смотрят на них с удивлением). | ||
Применение: хранение файлов большого объёма (например мультимедиа-данных) и файл-сервера для Windows-сетей. | Применение: хранение файлов большого объёма (например мультимедиа-данных) и файл-сервера для Windows-сетей. | ||
- | === [ | + | === [[:ruwp:JFS|jfs]] === |
Разработка IBM, использовавшаяся ранее на AIX, ныне портирована на OS/2 и Linux. В OS/2 имеет поддержку ACL и EA (уточнить про Linux). | Разработка IBM, использовавшаяся ранее на AIX, ныне портирована на OS/2 и Linux. В OS/2 имеет поддержку ACL и EA (уточнить про Linux). | ||
- | === [ | + | === [[:ruwp:Tmpfs|tmpfs]] === |
Специфическая файловая система, предназначенная для хранения временных файлов, которые не имеют ценности после перезагрузки ОС. В силу размещения в ОЗУ, крайне быстра. При этом, в случае размещения части данных в swap, преимущество в быстродействии хотя и падает, но сохраняется. Раздел tmpfs занимает столько памяти, сколько информации в нём размещено. Теоретически, можно задать размер раздела, превышающий размер ОЗУ+swap, но это не стоит делать по вполне понятным причинам. В идеальном случае, суммарный размер всех tmpfs-разделов должен быть меньше суммы ОЗУ+swap, однако могут быть и исключения, в зависимости от назначения tmpfs-разделов. Например, если точно известно, что они не будут одновременно использоваться на полный объём. | Специфическая файловая система, предназначенная для хранения временных файлов, которые не имеют ценности после перезагрузки ОС. В силу размещения в ОЗУ, крайне быстра. При этом, в случае размещения части данных в swap, преимущество в быстродействии хотя и падает, но сохраняется. Раздел tmpfs занимает столько памяти, сколько информации в нём размещено. Теоретически, можно задать размер раздела, превышающий размер ОЗУ+swap, но это не стоит делать по вполне понятным причинам. В идеальном случае, суммарный размер всех tmpfs-разделов должен быть меньше суммы ОЗУ+swap, однако могут быть и исключения, в зависимости от назначения tmpfs-разделов. Например, если точно известно, что они не будут одновременно использоваться на полный объём. | ||
Строка 134: | Строка 146: | ||
== Значение отдельных разделов == | == Значение отдельных разделов == | ||
- | ''Предлагаемые для разделов файловые системы и опции монтирования не следует рассматривать в качестве догмата. Так же, все рекомендуемые объёмы, со временем, будут расти.'' | + | ''Предлагаемые для разделов файловые системы и опции монтирования не следует рассматривать в качестве догмата. Так же, все рекомендуемые объёмы, со временем, будут расти.'' Подробно назначение каталогов описано в [[:ruwp:FHS|FHS]]. |
: '''{{path|/}}''' | : '''{{path|/}}''' | ||
Корневой раздел. На этом разделе лучше использовать ФС, которая надёжно восстанавливается после системных сбоев. Если предполагается выносить /usr, /var и /home на отдельные разделы, достаточно порядка 8Гб. | Корневой раздел. На этом разделе лучше использовать ФС, которая надёжно восстанавливается после системных сбоев. Если предполагается выносить /usr, /var и /home на отдельные разделы, достаточно порядка 8Гб. | ||
- | Примечание: в настоящее время существует мнение, что /usr не должен быть отдельным (при этом, некоторые современные init могут вести себя не очень адекватно при наличии отдельного /usr), поэтому, если не планируется отделять /usr, для рабочей станции делайте минимум 30-35Gb под корневой раздел, что бы избежать проблем с обновлением разрастающейся системы через пять-шесть лет. Если планируются отдельные /usr, /var, /home, /tmp, то достаточно 4-6 Гб. | + | Примечание: в настоящее время существует мнение, что /usr не должен быть отдельным (при этом, некоторые современные init могут вести себя не очень адекватно при наличии отдельного /usr), поэтому, если не планируется отделять /usr, для рабочей станции делайте минимум 30-35Gb под корневой раздел, что бы избежать проблем с обновлением разрастающейся системы через пять-шесть лет. Если планируются отдельные /usr, /var, /home, /tmp (/opt, /srv), то достаточно 4-6 Гб. |
Файловая система: ext4.<br> | Файловая система: ext4.<br> | ||
Строка 153: | Строка 165: | ||
Файловая система: ext4, возможно без журнала. Существует мнение, что лучше не монтировать её автоматически, а подключать только в моменты установки ядер и изменения конфигурации загрузчика. | Файловая система: ext4, возможно без журнала. Существует мнение, что лучше не монтировать её автоматически, а подключать только в моменты установки ядер и изменения конфигурации загрузчика. | ||
+ | |||
+ | Примечание: в некоторых других ОС GNU/Linux размеры initrd значительно превышают initrd в ALT Linux. | ||
+ | |||
+ | CentOS 7<br> | ||
+ | 43422696 initramfs-0-rescue-3dd51b8747f94aa49159fbac88313753.img<br> | ||
+ | 17854649 initramfs-3.10.0-229.11.1.el7.x86_64.img<br> | ||
+ | 19570267 initramfs-3.10.0-229.11.1.el7.x86_64kdump.img<br> | ||
+ | <br> | ||
+ | Ubuntu 14.04<br> | ||
+ | 27630536 initrd.img-3.13.0-79-generic<br> | ||
: '''{{path|/boot/efi}}''' | : '''{{path|/boot/efi}}''' | ||
Обязательный раздел в случае необходимости использования [[UEFI|UEFI-загрузчика]]. | Обязательный раздел в случае необходимости использования [[UEFI|UEFI-загрузчика]]. | ||
- | Файловая система - исключительно [ | + | Файловая система - исключительно [[:ruwp:FAT32|FAT32]]. |
+ | |||
+ | : '''{{path|/opt}}''' | ||
+ | |||
+ | В /opt устанавливаются приложения, не входящие в ОС. В обычном случае, этот каталог не используется, но может быть использован при работе с проприетарными приложениями. Например, в этот каталог попадают Adobe Acrobat Reader9, TeamViewer. Некоторые приложения, например, СУБД, могут занимать значительный объём. | ||
+ | |||
+ | Файловая система и опции монтирования - аналогично /usr. | ||
+ | |||
+ | : '''{{path|/srv}}''' | ||
+ | |||
+ | Cодержит данные для сервисов, предоставляемых системой. В частности, может быть использован [[Bacula|Бакулой]] для хранения архивов. В случае именно такого использования крайне рекомендуется делать отдельным разделом. Однако, чаще, данный каталог не используется. | ||
: '''{{path|/var}}''' | : '''{{path|/var}}''' | ||
Строка 165: | Строка 197: | ||
: '''{{path|/var/log}}''' | : '''{{path|/var/log}}''' | ||
- | Этот раздел делать отдельно очень полезно вообще, а для серверов - крайне необходимо. При сбоях или [ | + | Этот раздел делать отдельно очень полезно вообще, а для серверов - крайне необходимо. При сбоях или [[:ruwp:DoS-атака|DoS]] атаках размер журналов может резко увеличиваться, тем самым переполняя этот раздел. Если сервер используется для узкого круга задач (скажем web-сервер), есть смысл журнал основного сервиса вынести на отдельный раздел (скажем /var/log/apache). Например: |
/var/log — системные логи<br> | /var/log — системные логи<br> | ||
Строка 301: | Строка 333: | ||
Денис Смирнов — автор начальной версии этой статьи на freesource.info.<br> | Денис Смирнов — автор начальной версии этой статьи на freesource.info.<br> | ||
Клочков Роман — масса ценных комментариев к начальной версии Дениса Смирнова. | Клочков Роман — масса ценных комментариев к начальной версии Дениса Смирнова. | ||
+ | |||
+ | == Примечания == | ||
+ | <references/> |
Текущая версия на 07:57, 12 апреля 2017
Содержание |
Разбиение диска
Преамбула
Существует мнение, что, на рабочей станции, вообще не следует делить HDD/SSD на разделы (исключая /boot/efi и, вероятно, swap), особенно, если рабочей станцией пользуется один пользователь. Плюс такого решения исключительно в том, что не придётся решать вопрос о выборе размеров разделов. В случае такого выбора всю статью можно не читать, но стоит ознакомиться с написанным про разделы /boot/efi, swap и файловые системы btrfs и tmpfs.
Введение
Эта статья содержит информацию, которая может помочь принять решение о правильном выборе количества разделов, на которое следует разделить диск компьютера, о размере разделов, а также используемых на них файловых системах. Целью деления HDD на разделы является повышение быстродействия, надёжности и безопасности системы.
- Повышение надёжности следует из того, что не на всех разделах будут содержаться файлы, открытые для записи, и, соответственно, вероятность повреждения таких разделов при зависаниях и случайных нештатных перезагрузках будет минимальной. Например, необходимость отделения /var очевидна после изучения вывода
ls -l /proc/*/fd/ | grep "\s/var"
- Повышение быстродействия следует из того, что, во-первых, для каждого раздела можно выбрать наиболее оптимальный тип ФС, во-вторых, часть разделов можно вовсе убрать с механического носителя в ОЗУ и исключить лишнее обращение к механическому носителю (для SSD - ещё и уменьшить износ). Кроме того, файловые системы, требующие проверки после нештатных перезагрузок, не будут нуждаться в таковой проверке, если на них не будет файлов, открытых для записи (для этого следует отделять от корня разделы /var, /tmp, /home и, вероятно, /opt).
- Повышение безопасности достигается за счёт различных опций монтирования, ограничивающих те или иные права для разных разделов.
Есть мнение, что, по крайней мере, на тестовых машинах следует использовать LVM, который позволяет, при соблюдении ряда правил, гибко манипулировать разделами без потери данных. Но это тема отдельной статьи.
Загрузочный раздел GRUB для GPT
На дисках размером больше 2 Гб мы вынуждены отказаться от MBR и использовать GPT. Но таблица разделов GPT не оставляет места для грубовского загрузчика второго этапа (GRUB boot stage two): в случае GRUB в первом секторе (512 байт) располагается "заглушка" MBR с единственной записью - разделом тип GPT, а во втором секторе диска - уже GPT. (В классическом MBR секторы со 2 по 63 оставались зарезервированными и GRUB stage 2 записывался туда.) Поэтому в GPT для загрузчика второго этапа предусмотрен специальный тип раздела - "BIOS Boot Partition", который в parted и GpartEd обозначается флагом "bios_grub". В старой GRUB Wiki была рекомендация сделать раздел не менее 31 кБ размером и назначить ему в parted флаг "bios_grub". Red Hat рекомендует делать такой раздел размером 1 Мб.
- Если планируете установить на диск GRUB на диск с таблицей разделов GPT, обязательно создайте на этом диске раздел размером от 31 кб до 1 Мб и задайте ему флаг bios_grub, после чего выполните команду grub-install /dev/диск (для проверки).
Дисковая подкачка (swap)
У swap есть несколько особенностей.
- Если уж он используется, то доступ к нему должен быть максимально быстрый (а это значит либо начало, либо середина диска; для накопителей SSD место расположения, в плане скорости, значения не имеет).
- Данные в swap не представляют никакой ценности после перезагрузки машины.
- Если на компьютере (например, ноутбуке) планируется использовать режим гибернации, размер swap следует сделать несколько больше размера ОЗУ; если ОЗУ планируется наращивать в последствии, об этом лучше подумать заранее.
- Если для загрузки используете том RAID уровней больше 0, swap (тоже) располагайте на RAID-1, иначе при горячем отключении или поломке диска с размещённом на нём swap получите kernel panic.
Наилучшим решением считается держать swap в начале диска, это поможет спасти информацию на диске при повреждении по каким-либо причинам информации в начале диска. Пример такой причины — опечатка при работе с разделами (указали вместо /dev/sda2 просто /dev/sda).
Файловые системы
ext2
Когда-то традиционная для Linux файловая система. После появления ext3 и ext4 смысл её использовать есть только на разделах, которые должны поддерживаться сторонним программным обеспечением (например драйверами ext2 от других ОС), если таковое всё ещё не поддерживает ext3 или ext4.
Бывшее применение: разделы, к которым производилось обращение программ без помощи ОС (например lilo, grub и другие загрузчики).
На текущий момент, если это действительно необходимо, можно использовать ext4 с отключенным журналом, но работе lilo или grub журнал сейчас никак не мешает.
ext3
Сделана на базе ext2, отличается только наличием журналирования. Полностью обратно совместима с ext2 (то есть любое ПО, умеющее читать ext2, прочитает и ext3), конвертирование ext2 в ext3 заключается только в создании файла журнала (что делается командой tune2fs -j <устройство_с_FS>).
Единственная из описываемых поддерживает журналирование данных при использовании ядер 2.4.x, а не только метаданных (при использовании параметра data=journal), которое, как ни странно, в некоторых случаях даёт увеличение производительности. Одна из самых надёжных файловых систем для Linux, активно продвигалась компанией Red Hat, и была оттестирована на огромном количестве пользователей.
Бывшее применение: была самая универсальная файловая система под Linux, рекомендовалось использовать её как файловую систему для самых ценных данных, так как она была самая надёжная из описываемых.
На текущий момент ext4 не менее надёжна и, практически повсеместно, вытеснила ext3.
ext4
Пришла на смену ext3, обладает заметно лучшей производительностью благодаря использованию extent-ов.
Применение: ныне самая универсальная файловая система под Linux, рекомендуется использовать её как файловую систему для самых ценных данных, так как она является наиболее надёжной из современных ФС.
btrfs
Журналируемая файловая система нового поколения. Изначально разработана корпорацией Oracle, но, на текущий момент, в разработке участвуют RedHat и Fujitsu. ФС в стадии активной разработки, хотя базовый функционал считается уже стабильным. По скоростным характеристиками, по большей части, уступает остальным ФС, но значительно превосходит по возможностям (спорно относительно zfs).
Применение:
а) из простого - файловые системы большого размера и/или с большим количеством маленьких файлов;
б) из сложного - RAID средствами ФС (без mdadm), использование подразделов и т.п.
Примечание 1: использовать ядра младше 3.14 не рекомендуется; сложные конфигурации использовать без резервных копий не рекомендуется.
Примечание 2: с учётом использования подразделов, вероятно, имеет право на жизнь совмещение подхода, описанного в преамбуле, с тем, что описано в статье, с учётом, разумеется, использования исключительно btrfs.
zfs
Прогрессивная журналируемая файловая система, представленная Sun Microsystems в 2005 году в ОС OpenSolaris. Код ФС распространяется под лицензией CDDL, в силу этого не может быть включен в ядро Linux, однако модуль ФС присутствует во многих дистрибутивах Linux. Следует заметить, что Btrfs начинала разрабатываться, как конкурент ZFS, однако в 2010 году компания Sun Microsystems была куплена компанией Oracle.
Ключевой особенностью ZFS считается контроль над физическими и логическими носителями. Зная, как именно расположены данные на дисках, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных. Так же, как и btrfs, поддерживает разные уровни RAID и другие варианты объединения носителей в общее дисковое пространство.
reiserfs
Устаревшая в пользу Reiser4, однако, в отличие от Reiser4, включенная в основное ядро Linux, журналируемая файловая система, которая отличалась от других с точки зрения администратора, в первую очередь, хорошей скоростью работы с каталогами, в которых большое количество маленьких файлов. Как и в ext3 в ветке 2.6, в ней используются для поиска файла в каталоге B-tree и хэши. Кроме того она умеет компактно хранить хвосты от файлов для экономии места, обычно расходуемого впустую.
Ещё одно преимущество - длина имени файла ограничена 3968 байтами в случае 4к блока (4096 байт блока минус 128 байт заголовков)[1], тогда как в большинстве файловых систем она ограничена 255 байтами. При использовании кодировки UTF-8 имя файла на русском языке занимает в байтах вдвое больше места (а, например, символы китайского языка кодируются 4 байтами). К сожалению, в библиотеке glibc длина имени файла и каталога также ограничена 255 байтами, поэтому для поддержки длинных имён файлов нужно также патчить glibc. См. Ethersoft Wiki.
Применения:
- файловые системы с большим количеством маленьких файлов или с большим числом файлов в каталоге;
- в системе, собранной с модифицированным glibc — файловые системы с файлами с русскими именами и с именами на других национальных языках.
reiser4
Файловая система Reiser4 - наследница ReiserFS. На смену алгоритму B+-tree пришёл алгоритм dancing trees. Система была полностью подготовлена к включению в основное ядро Linux ещё в 2010 году, однако это не произошло. На текущий момент включение кода ФС в основное ядро не является приоритетом ввиду недостатка времени единственного оставшегося разработчика (в этом интервью Эдуард Шишкин сказал несколько слов и о btrfs, но это интервью 2010-ого года).
Применение: файловые системы с большим количеством маленьких файлов, или в которых большое количество файлов в каталоге.
Примечание: в ALT Linux нет готовых ядер с поддержкой Reiser4.
xfs
Разработка SGI, перенесённая в Linux. Присутствует в ядре, начиная с ядра 2.4.25. Оптимизированная для быстрой работы с файлами большого размера (multimedia данных), обладающая великолепной надёжностью, имеющая поддержку ACL (полезно для файл-серверов с Windows-клиентами) и EA (до конца зачем они нужны понимают лишь бывшие пользователи OS/2, остальные смотрят на них с удивлением).
Применение: хранение файлов большого объёма (например мультимедиа-данных) и файл-сервера для Windows-сетей.
jfs
Разработка IBM, использовавшаяся ранее на AIX, ныне портирована на OS/2 и Linux. В OS/2 имеет поддержку ACL и EA (уточнить про Linux).
tmpfs
Специфическая файловая система, предназначенная для хранения временных файлов, которые не имеют ценности после перезагрузки ОС. В силу размещения в ОЗУ, крайне быстра. При этом, в случае размещения части данных в swap, преимущество в быстродействии хотя и падает, но сохраняется. Раздел tmpfs занимает столько памяти, сколько информации в нём размещено. Теоретически, можно задать размер раздела, превышающий размер ОЗУ+swap, но это не стоит делать по вполне понятным причинам. В идеальном случае, суммарный размер всех tmpfs-разделов должен быть меньше суммы ОЗУ+swap, однако могут быть и исключения, в зависимости от назначения tmpfs-разделов. Например, если точно известно, что они не будут одновременно использоваться на полный объём.
Применение: подходит для раздела /tmp, разделов для сборки ПО (например, для раздела, заданного макросом %_tmppath у RPM).
Параметры монтирования
Есть набор параметров монтирования, поддерживаемых всеми файловыми системами, а также есть параметры конкретной файловой системы. Эта информация взята из mount(8). Здесь описаны некоторые параметры, на которые стоит обратить внимание в первую очередь.
Общие параметры монтирования
- noatime — при каждом доступе (в том числе чтении) к файлу в inode обновляется время последнего доступа к файлу, что требуется крайне редко, при использовании этого параметра это обновление производиться не будет, что заметно ускорит работу news-серверов, и, в особенности, прокси-сервера squid (так как он каждую секунду выполняет несколько обращений к файлам на чтение, каждое из которых без noatime вызывает операцию записи, то есть обновления информации о времени последнего доступа).
- nodev — не позволяет создавать и использовать на этой файловой системе файлы-устройства, эта возможность полезна для безопасности (если вы точно знаете, что на данной файловой системе файлы-устройства вам не нужны, то есть смысл ставить этот параметр).
- nosuid — на этой файловой системе не действует бит suid (исполнение программы от имени её владельца, а не запустившего её пользователя).
- noexec — запрет запуска с этой файловой системы (внимание! скрипты всё равно можно будет запустить командой bash скрипт.sh).
- ro — доступ только для чтения
ext4
- data=journal — все данные сначала пишутся в журнал, прежде чем начать запись на файловую систему
- data=ordered — (режим по умолчанию) сначала пишутся данные прямо в файловую систему, после чего метаданные добавляются в журнал
- data=writeback — очерёдность записи не соблюдается, метаданные могут быть записаны в журнал до того, как данные будут записаны на файловую систему, хотя этот режим гарантирует целостность файловой системы, он может позволить устаревшим данным присутствовать в файлах после сбоя (и, соответственно, восстановления журнала). Этот режим используется для увеличения производительности
reiserfs
- notail — отключение ускорения доступа к маленьким файлам и упаковки «хвостов файлов». Она была нужна в те времена, когда загрузчик ядра (LILO) не понимал где искать «хвосты». Кроме того с этим параметром не будет часто замечаемого многими пользователя «обрывков других файлов в файле» после аппаратный сбоев.
Поддерживается в дистрибутивах ALT Linux, выпущенных с начала 2004 года:
- data=journal — данные сначала пишутся в журнал, а потом начинается запись на файловую систему
- quota — для управления квотами пользователей на дисковое пространство
xfs
- dmapi
- logdev=device — путь к устройству, на котором будет размещён журнал
- osyncisdsync
- quota / usrquota / ugnoenforce
- grpquota / gqnoenforce
tmpfs
- size=5G - задать размер tmpfs (в примере - 5Гб); если параметр не указывать, размер будет соответствовать 50% ОЗУ.
Значение отдельных разделов
Предлагаемые для разделов файловые системы и опции монтирования не следует рассматривать в качестве догмата. Так же, все рекомендуемые объёмы, со временем, будут расти. Подробно назначение каталогов описано в FHS.
- /
Корневой раздел. На этом разделе лучше использовать ФС, которая надёжно восстанавливается после системных сбоев. Если предполагается выносить /usr, /var и /home на отдельные разделы, достаточно порядка 8Гб.
Примечание: в настоящее время существует мнение, что /usr не должен быть отдельным (при этом, некоторые современные init могут вести себя не очень адекватно при наличии отдельного /usr), поэтому, если не планируется отделять /usr, для рабочей станции делайте минимум 30-35Gb под корневой раздел, что бы избежать проблем с обновлением разрастающейся системы через пять-шесть лет. Если планируются отдельные /usr, /var, /home, /tmp (/opt, /srv), то достаточно 4-6 Гб.
Файловая система: ext4.
Опции монтирования: в зависимости от наличия в корне остальных разделов.
- /usr
Обычно достаточно большой раздел (20-30Гб), который редко разбивается на подразделы. Объём зависит от количества и назначения устанавливаемого ПО: некоторые приложения (офисные пакеты, игры и т.п.) могут занимать много места (игра VegaStrike, к примеру, требует 1.2Гб). Рекомендуется минимум 20Gb для рабочей станции.
- /boot
На этом разделе обычно лежат рабочее и failsafe ядра, initrd образы, system.map файлы, а также некоторые данные используемого загрузчика (lilo или grub). Если этот раздел вообще создавать, объём следует выбирать, исходя из желаемого количества запасных ядер. Ядро 4.4 с соответствующим initrd занимает около 10М, файлы grub2 около 4.5Мб. Объёма 100Мб, таким образом, должно хватить на эксперименты с 9-ю ядрами. При этом, следует учесть, что объёмы, занимаемые ядром и initrd растут из года в год, потому не стоит делать раздел впритык, оставьте запас на будущее.
Раздел часто используется в системах с программным RAID с уровнями, отличными от 1, так как загрузчики могут работать именно с RAID 1. Так же раздел может быть использован в ситуациях, когда BIOS не работает с HDD большого объёма - в этом случае небольшой раздел в начале позволяет не задумываться о проблемах с BIOS (в этом случае раздел должен целиком попасть в область, которую видит BIOS).
Файловая система: ext4, возможно без журнала. Существует мнение, что лучше не монтировать её автоматически, а подключать только в моменты установки ядер и изменения конфигурации загрузчика.
Примечание: в некоторых других ОС GNU/Linux размеры initrd значительно превышают initrd в ALT Linux.
CentOS 7
43422696 initramfs-0-rescue-3dd51b8747f94aa49159fbac88313753.img
17854649 initramfs-3.10.0-229.11.1.el7.x86_64.img
19570267 initramfs-3.10.0-229.11.1.el7.x86_64kdump.img
Ubuntu 14.04
27630536 initrd.img-3.13.0-79-generic
- /boot/efi
Обязательный раздел в случае необходимости использования UEFI-загрузчика.
Файловая система - исключительно FAT32.
- /opt
В /opt устанавливаются приложения, не входящие в ОС. В обычном случае, этот каталог не используется, но может быть использован при работе с проприетарными приложениями. Например, в этот каталог попадают Adobe Acrobat Reader9, TeamViewer. Некоторые приложения, например, СУБД, могут занимать значительный объём.
Файловая система и опции монтирования - аналогично /usr.
- /srv
Cодержит данные для сервисов, предоставляемых системой. В частности, может быть использован Бакулой для хранения архивов. В случае именно такого использования крайне рекомендуется делать отдельным разделом. Однако, чаще, данный каталог не используется.
- /var
Раздел, предназначенный для хранения изменяемых в процессе работы системы данных. Кроме того, в нём располагается каталог /var/lib, где расположены chroot-окружения ряда пакетов (при этом, есть исключение в виде chroot резолвера - /var/resolv).
Файловая система и опции монтирования - в зависимости от того, есть ли деление на разделы внутри /var.
- /var/log
Этот раздел делать отдельно очень полезно вообще, а для серверов - крайне необходимо. При сбоях или DoS атаках размер журналов может резко увеличиваться, тем самым переполняя этот раздел. Если сервер используется для узкого круга задач (скажем web-сервер), есть смысл журнал основного сервиса вынести на отдельный раздел (скажем /var/log/apache). Например:
/var/log — системные логи
/var/log/apache — логи www-сервера
Файловая система: ext4, xfs.
Опции монтирования: noatime, noexec, nodev.
- /var/spool
Различные спулы, как с данными временного (очереди почтовых сообщений или очереди печати), так и постоянного (электронная почта пользователей) хранения.
Файловая система: reiserfs, ext4.
Опции монтирования: noexec, nodev.
- /var/spool/mail
Файловая система: каталог с почтой пользователей.
Файловая система: ext4 с data=journal.
Опции монтирования: noatime, noexec, nodev.
Также на этот раздел полезно устанавливать квоты.
Примечание: использование современных POP/IMAP серверов может привести к изменению места хранения почты (в соответствии с особенностями выбранного ПО).
- /var/cache
Всякие кэши.
Файловая система: ext4, reiserfs.
Опции монтирования: noexec, nodev, noatime.
- /var/tmp
Эта файловая система предназначена, в первую очередь, для хранения временных данных, которые могут иметь смысл после сбоя сервера (например данные autosave, или журнал работы текстовых редакторов). Предназначен исключительно для файлов данных и должен обеспечивать высокую надёжность при аппаратных и программных сбоях.
Файловая система: ext4.
Опции монтирования: data=journal, noexec, nodev, atime.
- /var/www
Раздел с сайтами пользователей
- /var/run (/run)
надо описать.
Файловая система: runfs (tmpfs)
- /var/lock
надо описать.
Файловая система: tmpfs
- /tmp
Каталог для временных файлов, не имеющих никакого смысла при перезагрузке. Может пересоздаваться во время загрузки системы.
Время последнего доступа к файлу может использоваться для проверки, не является ли файл в этом каталоге неиспользуемым (скажем если к файлу не было доступа больше трёх суток, и он никем не открыт, то он удаляется), поэтому желательно держать флаг atime.
Файловая система: tmpfs, reiserfs
Опции монтирования: nodev, atime.
- /home
Домашние каталоги пользователей. На серверной машине, на которой у пользователей нет shell-доступа, скорее всего, имеет смысл ставить на этот раздел флаг noexec, но если он не ставится, то nosuid обязателен.
Время последнего доступа к файлам, если раздел используется несколькими реальными пользователями, может быть нужно, поэтому в этом случае noatime не нужен. Однако, если машина используется, скажем, как почтовый сервер (то есть пользователи никогда не сталкиваются с данными на файловой системе), то, скорее всего, этот флаг вам нужен.
Файловая система: ext4, xfs
Опции монтирования: nosuid, nodev
- /dev
Каталог на корневом разделе, содержащий специальным образом созданные файлы - ссылки на устройства. Как правило, перемонтирован посредством udev и, в обычной системе, является разделом с udevfs.
Специальные файловые системы , создаваемые ядром Linux.
- /proc
Псевдо-файловая система, которая используется в качестве интерфейса к структурам данных в ядре.
- /sys
Псевдо-файловая система, часть единой унифицированной модели представления устройств в Linux.
Примеры
Примеры представлены, как есть, в качестве наглядных иллюстраций по разделению диска и назначению опций монтирования. Бездумное копирование примеров может оказаться неправильным решением.
Опции монтирования по-умолчанию (altlinux-p7-sysv-tde)
proc /proc proc nosuid,noexec,gid=proc 0 0 devpts /dev/pts devpts nosuid,noexec,gid=tty,mode=620 0 0 tmpfs /tmp tmpfs nosuid 0 0 /dev/sda1 swap swap defaults 0 0 /dev/sda5 / ext4 relatime 1 1 /dev/sda2 /boot ext4 nodev,nosuid,noexec,relatime 1 2 /dev/sda8 /home ext4 nosuid,relatime 1 2 /dev/sda6 /usr ext4 nodev,relatime 1 2 /dev/sda7 /var ext4 nosuid,relatime 1 2 /dev/sda10 /var/ftp ext4 nodev,nosuid,noexec,relatime 1 2
Размеры и разделы: рабочая станция
Filesystem Size Used Avail Use% Mounted on udevfs 5.0M 0 5.0M 0% /dev runfs 1.3G 464K 1.3G 1% /run /dev/sda5 3.9G 845M 2.8G 23% / shmfs 1.3G 216K 1.3G 1% /dev/shm tmpfs 7.0G 2.7M 7.0G 1% /tmp /dev/sda2 488M 27M 426M 6% /boot /dev/sda8 30G 25G 3.2G 89% /home /dev/sda6 20G 9.1G 9.5G 49% /usr /dev/sda7 9.8G 1.5G 7.9G 16% /var /dev/sda10 113G 105G 2.2G 99% /var/ftp /dev/sda9 40G 30G 7.5G 81% /home/user/RPM tmpfs 5.0G 645M 4.4G 13% /home/user/tmp-build tmpfs 5.0G 545M 4.5G 11% /home/user/RPM/BUILD
Примечание: /dev, /run и /dev/shm созданы приложением udev.
Размеры и разделы: рабочая станция (один раздел + /boot/efi)
Filesystem Size Used Avail Use% Mounted on udevfs 5.0M 0 5.0M 0% /dev runfs 1.8G 1.2M 1.8G 1% /run /dev/sda4 110G 86G 19G 83% / tmpfs 1.8G 21M 1.8G 2% /dev/shm tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup /dev/sda1 248M 119K 248M 1% /boot/efi tmpfs 367M 24K 367M 1% /run/user/500
Ссылки
- HOWTO: Multi Disk System Tuning
- Linux Partition HOWTO
- fuse -- инструмент для создания виртуальных файловых систем
- plasticfs -- файловая система в userspace
- filesystems.org -- разработка ФС сразу для Linux, Solaris и FreeBSD
-
unionfs -- A Stackable Unification File Systemустарела, см. aufs и overlayfs
Благодарности
Денис Смирнов — автор начальной версии этой статьи на freesource.info.
Клочков Роман — масса ценных комментариев к начальной версии Дениса Смирнова.