10 января 2006 17:05 | vjp7:
>> On 06.01.10 09:33, Крохин Анатолий Александрович wrote:
>> On Wed, 28 Dec 2005 18:32:07 +0300
>> Alexander <aral***@m*****.ru> wrote:
>>
>>>> 2. Необходимо 1 раздел или 2 (мне говорили что под своп нужен
>>>> отдельный раздел)
>>
>> Чушь полная. Нет такой НЕОБХОДИМОСТИ.
>
> IMHO, стоит воздержаться от подобный резкости высказывания,
> не имея достаточных на то оснований. Тем паче что в любой
> литературе наберется вагон и маленькая тележка сведений
> по данному вопросу и отнюдь не с такой точкой зрения.
Тем не менее, Анатолий совершенно прав в том, что для этого нет никакой
технической необходимости. Проще говоря, это не является требованием
системы.
> Вот мое разбиение.
Отлично, наверное, у Вас есть на то причины (требования пользователя).
Однако не всем это подходит, например, хотя бы из-за того, что это
фрагментирует дисковое пространство. Дико неудобно, когда в / у вас еще
гигабайт-другой, а, например, в /home уже считаем последние десятки метров.
Разбиение диктуется применением и для домашней/экспериментальной установки
такое разбиение имеет очень мало смысла.
>> Своп потом можно будет поместить в файл.
> Если Вы хотите, чтобы операции с памятью проходили еще и
> через функции файловой системы, так и поступите.
Накладные расходы на работу свопа из файла просто мизерны. Микросекунды
процессорного времени ничто в сравнении с миллисекундами перемещения
головок винчестера.
Другое дело, что у такого подхода есть другой недостаток - фрагментированный
файл действительно может снизить скорость работы свопа. В этом случае
скорость работы свопа будет где-то такая же как и у Windows. Для многих
применений достаточно, учитывая некоторые удобства свопа в файле.
>> Да. И еще одно соображение - к разделам, которые находятся ближе к
>> началу диска доступ осуществляется быстрее. Из этого расчета я
>> стараюсь поместить своп поближе к началу.
>
> Не слишком критично для SCSI и SATA.
Пока у нас механические винчестеры с круглыми блинами, это имеет смысл. Если
окончательное разбиение еще не произведено (и принято решение о выделении
отдельного раздела для свопа), это стоит принять во внимание.
> Файловые системы Linux'а весьма чувствительны к аварийным
> выключениям/перезагрузкам (были преценденты с ReiserFS и XFS).
Нет. Это не так. Журналируемые файловые системы типа ext3, ReiserFS, XFS
(ОК, эта моложе всех, потому вероятность отказа будет повыше) вполне
спокойно переносят аварийные ситуации. Целостность данных не гарантирует
никто, но это справедливо для любой сегодняшней ФС (хотя Reiser4 почти к
этому готов), а вот целостность файловой системы гарантирует журнал.
Инциденты в смысле нарушения целостности самой ФС? Бывают. Бывают абсолютно
у всех файловых систем. В конце концов, даже ядра операционных систем, даже
Linux, иногда падают. Не зря в мире программного обеспечения до сих пор ни
один производитель ничего не гарантирует потребителю...
