зачем помещать вещи, отличные от / home, в отдельный раздел?

<p>поэтому недавно установщик debian 5.0.5 предложил мне иметь отдельный <code>/usr</code>, <code>/home</code>, <code>/var</code> а также <code>/tmp</code> разделы (на одном физическом диске).</p><p>какова практическая причина этого? я это понимаю <code>/home</code> может быть выгодно поместить в отдельный раздел, потому что пользовательские файлы могут быть зашифрованы отдельно, но зачем вообще что-то еще?</p>

<ol> <li>минимизация потерь: если <code>/usr</code> находится в отдельном разделе, поврежден <code>/usr</code> не означает, что вы не можете восстановить <code>/etc</code>.</li> <li>безопасность: <code>/</code> не всегда может быть ro (<code>/root</code> может потребоваться rw и т. д.) но <code>/usr</code> можно. это может быть использовано, чтобы сделать ро как можно больше.</li> <li>использование разных fs: я могу использовать другую систему для <code>/tmp</code> (не надежно, но быстро для многих файлов) и <code>/home</code> (должно быть надежным). схожий <code>/var</code> содержит данные, а <code>/usr</code> не так <code>/usr</code> стабильность может быть жертвой, но не настолько, как <code>/tmp</code>.</li> <li>продолжительность fsck: меньшие разделы означают, что проверка одного происходит быстрее.</li> <li>упоминается заполнение разделов, хотя другим методом является квота.</li> </ol>

<p>отдельный <code>/usr</code> может быть полезно, если у вас есть несколько компьютеров с одной ос. они могут совместно использовать один центральный <code>/usr</code> вместо дублирования в каждой системе. <code>/usr</code> может быть смонтирован только для чтения.</p><p><code>/var</code> а также <code>/tmp</code> может быть заполнено пользовательскими программами или демонами. поэтому может быть безопасно иметь их в отдельных разделах, которые будут препятствовать <code>/</code>, корневой раздел, будет заполнен на 100% и сильно ударит по вашей системе. чтобы избежать наличия двух отдельных разделов для них, нередко видеть <code>/tmp</code> является символической ссылкой на <code>/var/tmp</code>.</p>

<p>потому что обычные пользователи могут заставить вещи быть записанными в <code>/var</code> а также <code>/tmp</code>, и, следовательно, потенциально может вызвать проблемы для всей системы. таким образом, пользовательские процессы могут заполняться <code>/var</code> а также <code>/tmp</code>, но не корневой фс. отдельный <code>/usr</code> полезно для <code>/usr</code> через nfs или другой удаленный фс.</p><p>(надеюсь, это понятно, я еще не пил кофе)</p>

<p>проблема в том, что полный root fs делает систему linux неработоспособной до такой степени, что даже администратор исправляет ее без cd восстановления или подобного. когда <code>/tmp</code> а также <code>/var</code> и в частности <code>/home</code> находятся в отдельном разделе, корневой фс никогда не сможет заполниться, если этого не сделает администратор. взять <code>/usr</code> в миксе, в который будут помещены все обычные установки, и даже установка нового программного обеспечения не может вызвать эту проблему.</p>

<p>как правило, аргументы для наличия отдельных разделов:</p><ol> <li> <p>безопасность: вы можете, например, смонтировать раздел только для чтения, чтобы злоумышленники (или процессы) не могли перезаписывать или заменять двоичные файлы там троянами. поэтому, если ваш двоичный файл ssh находится в/usr/local/bin, а/usr/local смонтирован только для чтения, заменить этот двоичный файл будет непросто.</p> </li> <li> <p>гибкость/удобство: например, если вы настроили/var на свой собственный раздел, и он заполнен на 80%, вы можете изменить его размер или даже перенести его на другой диск, если это необходимо. я бы предпочел сделать это, чем иметь дело с системой, у которой '/' заполнена на 100%, потому что журналы в/var в некотором роде потеряли свою актуальность. разные разделы могут также иметь разные файловые системы, что позволяет вашей операционной системе использовать ext3 (например) и вашей базе данных использовать ext4, или вашему хранилищу объектов для использования xfs, или вашему пользовательскому приложению для использования ... необработанных устройств!</p> </li> </ol>

<p>традиционно, это было сделано из-за особенностей аппаратного обеспечения dec, на котором оно было разработано. было выгоднее купить маленький быстрый диск для root и swap и больший, более медленный диск для пользовательских данных (<code>/usr</code>). в некоторых отношениях конвенция просто застряла.</p><p>однако есть еще несколько причин для этого. несколько общих из них:</p><ul> <li> <p>помещение/boot на отдельный маленький раздел рядом с началом диска. более старая прошивка bios пк загружалась только с первых 1024 дорожек диска. это менее вероятно, будет проблемой с современным оборудованием.</p> </li> <li> <p>ввод занятых разделов, таких как <code>/var</code> или <code>/tmp</code> на отдельные диски для устранения узких мест при доступе к пользовательским данным.</p> </li> <li> <p>разные файловые системы на разных разделах. например, вы можете использовать журналирующую файловую систему для <code>/usr</code>, но не для разделов, которые размещают файлы для субд, такой как oracle - субд выполняет собственные журналирования, а файловая система журналирования может налагать значительные накладные расходы.</p> </li> <li> <p>наличие пользовательских данных на отдельном диске или разделе позволяет легко перенести их на большой диск без каких-либо серьезных операций на компьютере.</p> </li> <li> <p>вы можете подключить общие данные, такие как домашние каталоги или двоичные файлы приложений, по nfs.</p> </li> <li> <p><code>fsck</code> занимает много времени на больших томах для определенных типов файловой системы. возможно, вы захотите иметь разные графики обслуживания файловой системы для системных областей (часто) и пользовательских областей (менее часто).</p> </li> </ul>

<p>форматирование файловой системы также может быть быстрее, чем rm -rf'ing. особенно, если вам нужно стереть тысячи маленьких файлов. кеш squid вы хотите полностью воссоздать ... тонны файлов изображений, которые вам нужны для обработки, но которые можно выбросить после создания конечного результата. файлы .obj из огромных компиляций ... и т. д.</p>

<p>папка, которую я иногда помещаю в отдельный раздел - <code>/usr/local/</code>, чтобы любое программное обеспечение, которое я собрал и установил отдельно от диспетчера пакетов моего дистрибутива, могло быть повторно использовано, если я изменил/обновил свой дистрибутив или другой дистрибутив, установленный рядом с ним. очевидно, что не гарантируется работа со всеми возможными комбинациями, но это не вредит.</p>

<p>я кладу <code>/tmp</code> в tmpfs, поэтому содержимое хранится в ram, а не на диске. это не будет полезно для <code>/etc</code> или <code>/usr</code> однако.</p><p>но возможность размещать разные каталоги в разных файловых системах может быть полезной; то есть <code>/home</code> в быстрой/экспериментальной файловой системе, такой как ext4, по сравнению со стабильной/надежной файловой системой, такой как ext2 для <code>/etc</code>.</p>