Re: Посоветуйте начинающему

On Wed, 28 Dec 2005 18:32:07 +0300
Alexander <aral***@m*****.ru> wrote:

Целое маленькое пособие накатал. ;) Пару замечаний.

Это вам везло похоже. Не раз слышал, что сегодня есть, а завтра нет.
Зато никаких гадостей не слышал об ext. :)

У меня:
$ free
total used free shared buffers cached
Mem: 1036616 466516 570100 0 23180 221840
-/+ buffers/cache: 221496 815120
Swap: 0 0 0

свободно больше половины. При сборке ядра тоже что-то оставалось, кажись
метров 200. Так что если хотя бы 512 метров ОЗУ есть, я бы уже думал.

Или купить. На двд ;). В Украине это lafox.net, в России кажись opennnet.ru,
пусть
меня поправят.

3 января 2006 18:46 | Matvey:

Нет. Это кому как везло. Про ext тоже можно начитаться всяких гадостей,
было бы желание. :) Есть только один факт - ReiserFS значительно быстрее
ext3, но ровно до тех пор, пока на нем не пытаются использовать ACL. ACL
к Reiser был притянут за уши и работает на нем просто отвратно, это факт.

Личный опыт использования ReiserFS у меня вылился в две встречи с
`reiserfsck --rebuild-tree`. Первая однозначно была вызвана использованием
cryptoloop (он далек от стабильности), про вторую, к сожалению, ни черта не
помню, в тот момент было совсем не до анализа ситуации. В обоих случаях все
было успешно восстановлено.

Это на личной машине, над которой я издеваюсь по всякому. На соседней
ставились всякие разные дистрибутивы (пока не успокоился на Gentoo), со
всеми использовался ReiserFS и проблем я вообще не видел.

Только не надо думать, что я хочу сказать, что ReiserFS стабильнее, чем
ext3. Нет. В этом смысле обе две где-то на одном уровне, чаще подводит
аппаратура, нежели эти ФС.

Да, параллельно насчет развития - развитие ReiserFS фактически отсутствует,
впрочем, равно как и у ext3. Обе достаточно стабильны, обе работают, но в
обоих периодически вылавливают и исправляют ошибки. Reiser4 же написана с
нуля и сейчас пытается пробиться в основную ветку ядра.

On Wed, 28 Dec 2005 18:32:07 +0300
Alexander <aral***@m*****.ru> wrote:

Необходимости? Пожалуй нет. Но я бы посоветовал все-таки сделать, как
минимум, 2 раздела. Вынести в отдельный раздел /usr/local и/или /home
для того, чтобы когда будете делать переустановку (например для
апгрейда) на нем (на них) сохранить информацию, которую не хотелось бы
терять при переформатировании других разделов.

А своп я бы посоветовал все-таки делать в отдельном разделе. Если его
делать....

Да. И еще одно соображение - к разделам, которые находятся ближе к
началу диска доступ осуществляется быстрее. Из этого расчета я стараюсь
поместить своп поближе к началу.

On 06.01.10 09:33, Крохин Анатолий Александрович wrote:

IMHO, стоит воздержаться от подобный резкости высказывания,
не имея достаточных на то оснований. Тем паче что в любой
литературе наберется вагон и маленькая тележка сведений
по данному вопросу и отнюдь не с такой точкой зрения.

Вот мое разбиение.

#df
Файловая система 1K-блоков Исп Доступно Исп% смонтирована на
/dev/sda1 4999416 1571892 3427524 32% /
/dev/sda2 252240 13496 238744 6% /boot
/dev/sda4 21934056 11989116 9944940 55% /mnt/t2
/dev/sda5 2364756 663024 1701732 29% /home
/dev/sda6 4999416 3351472 1647944 68% /usr/local
/dev/sda7 4999416 1329656 3669760 27% /var
/dev/sda9 18552832 9834224 8718608 54% /mnt/t1

#fdisk /dev/sda
Device Boot Start End Blocks Id System
..
/dev/sda8 2197 2379 1469916 82 Linux swap / Solaris
..

А еще нужно для /tmp отдельный раздел.

Если Вы хотите, чтобы операции с памятью проходили еще и
через функции файловой системы, так и поступите.

Не слишком критично для SCSI и SATA.

Файловые системы Linux'а весьма чувствительны к аварийным
выключениям/перезагрузкам (были преценденты с ReiserFS и XFS).
Потому UPS - forever и не кладите все яйца в одну корзину.

Best regards,
vjp7 <vj***@g*****.net>

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 23615; Возраст листа: 900; Участников: 1465
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/499761

10 января 2006 17:05 | vjp7:

Тем не менее, Анатолий совершенно прав в том, что для этого нет никакой
технической необходимости. Проще говоря, это не является требованием
системы.

Отлично, наверное, у Вас есть на то причины (требования пользователя).
Однако не всем это подходит, например, хотя бы из-за того, что это
фрагментирует дисковое пространство. Дико неудобно, когда в / у вас еще
гигабайт-другой, а, например, в /home уже считаем последние десятки метров.
Разбиение диктуется применением и для домашней/экспериментальной установки
такое разбиение имеет очень мало смысла.

Накладные расходы на работу свопа из файла просто мизерны. Микросекунды
процессорного времени ничто в сравнении с миллисекундами перемещения
головок винчестера.

Другое дело, что у такого подхода есть другой недостаток - фрагментированный

файл действительно может снизить скорость работы свопа. В этом случае
скорость работы свопа будет где-то такая же как и у Windows. Для многих
применений достаточно, учитывая некоторые удобства свопа в файле.

Пока у нас механические винчестеры с круглыми блинами, это имеет смысл. Если

окончательное разбиение еще не произведено (и принято решение о выделении
отдельного раздела для свопа), это стоит принять во внимание.

Нет. Это не так. Журналируемые файловые системы типа ext3, ReiserFS, XFS
(ОК, эта моложе всех, потому вероятность отказа будет повыше) вполне
спокойно переносят аварийные ситуации. Целостность данных не гарантирует
никто, но это справедливо для любой сегодняшней ФС (хотя Reiser4 почти к
этому готов), а вот целостность файловой системы гарантирует журнал.

Инциденты в смысле нарушения целостности самой ФС? Бывают. Бывают абсолютно
у всех файловых систем. В конце концов, даже ядра операционных систем, даже
Linux, иногда падают. Не зря в мире программного обеспечения до сих пор ни
один производитель ничего не гарантирует потребителю...

On 06.01.10 23:26, Roman I Khimov wrote:

Это является требованием здравого смысла и надежности системы.

При грамотно спроектированном разбиении и современных ценах
на носители некритично.

Если народ вовсю играет с флагами компилятора для достижения
максимальной производительности, то разместить своп в файле
по меньшей мере нерационально. И если в этот момент
процессор сильно занят, это неизбежно скажется на
производительности дисковой подсистемы.

Вряд ли он будет сильно фрагментирован. Ведь файл подкачки
будет создан один раз с фиксированным размером в момент
установки системы с минимальным заполнением дисков и
минимальной фрагментацией ФС. Но этот нюанс, конечно же,
тоже стоит принять во внимание.
Многое зависит также от железа (диск, процессор, объем
памяти) и выбранной FS. Если посмотреть на
http://www.namesys.com/benchmarks.html, то можно заметить, что
Reiser4 съедает в два раза больше ресурсов процессора, чем ext2,
XFS и ReiserFS. Так что у размещения свопа в отдельном разделе
(а лучше на другом физическом носителе) есть свои преимущества.

1. Диск SAMSUNG SP0812C SATA 80 GB:

#hdparm -t /dev/sda1
/dev/sda1:
Timing buffered disk reads: 118 MB in 3.03 seconds = 38.99 MB/sec

#hdparm -t /dev/sda4

/dev/sda4:
Timing buffered disk reads: 102 MB in 3.08 seconds = 33.10 MB/sec

Разница 15%.

2. Диск SEAGATE ST336807LC SCSI 36.7 GB:

#hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 116 MB in 3.01 seconds = 38.53 MB/sec

#hdparm -t /dev/sda3

/dev/sda3:
Timing buffered disk reads: 144 MB in 3.02 seconds = 47.61 MB/sec

Разница (обратная!) 23%.

3. Диск IBM DDYS-T18350N SCSI 19 GB:

#hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 104 MB in 3.04 seconds = 34.26 MB/sec

#hdparm -t /dev/sda2

/dev/sda2:
Timing buffered disk reads: 78 MB in 3.02 seconds = 25.81 MB/sec

Разница 25%.

4. Диск SEAGATE ST320082 2AS PATA 200 GB через USB:

#hdparm -t /dev/sdb1

/dev/sdb1:
Timing buffered disk reads: 60 MB in 3.06 seconds = 19.64 MB/sec

hdparm -t /dev/sdb4

/dev/sdb4:
Timing buffered disk reads: 62 MB in 3.08 seconds = 20.12 MB/sec

Разница (обратная) 2%.

5. Диск SEAGATE ST94011A 2.5" 40 GB через USB:

#hdparm -t /dev/sdb1

/dev/sdb1:
Timing buffered disk reads: 26 MB in 3.19 seconds = 8.15 MB/sec

#hdparm -t /dev/sdb2

/dev/sdb2:
Timing buffered disk reads: 30 MB in 3.25 seconds = 9.23 MB/sec

Разница (обратная) 13%.

6. Диск IBM IC35L080AVVA07-0 PATA 80 GB:

#hdparm -t /dev/hda1

/dev/hda1:
Timing buffered disk reads: 106 MB in 3.00 seconds = 35.32 MB/sec

#hdparm -t /dev/hda6

/dev/hda6:
Timing buffered disk reads: 70 MB in 3.07 seconds = 22.77 MB/sec

Разница 35%.

Вы правы - каждую модель хорошо бы тестировать перед разбиением.

Да, это так. Говорю только за себя. Все файловые системы у меня на XFS.
Последний сбой, произошедший пару месяцев назад, привел к
невозможности автоматического восстановления ФС, по совету xfs_check
пришлось делать так:
#xfs_repair -L /dev/sda9
Цитирую ман:
..
-L Force Log Zeroing. Forces xfs_repair to zero
the log even if it is dirty (contains metadata
changes). When using this option the
filesystem will likely appear to be corrupt, and can
cause the loss of user files and/or data.
..

Правда, потери были минимальны, системы и большинства данных они не
коснулись, что однозначно произошло бы в случае размещения всего и всех
на одном разделе (это шпилька :))) . А вот двумя годами ранее слетела
ReiserFS с полной потерей ФС и после всяческого тестирования и сбора
данных о ФС-ах было принято решение остановиться на XFS.

Все так. Но находясь в самом начале, почему бы сразу не
сделать правильно и не наступать на грабли, по которым уже
кто-то прошел?

С уважением,
vjp7 <vj***@g*****.net>

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 23651; Возраст листа: 901; Участников: 1465
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/499968

11 января 2006 09:14 | vjp7:

Все-таки не совсем. :) Это нужно, когда это нужно, как и всегда. Для
домашних/экспериментальных целей это то, что называется overkill (тема у
нас по-прежнему "Посоветуйте начинающему"). Оценить при первой установке,
сколько тебе куда понадобиться места просто невозможно. :)

Просто, на данном этапе попытка "хитрого" разбиения однозначно приведет к
каким-то перегибам, на которые потом человек будет страшно ругаться. Он
откусил последние гигабайты свободного места от разделов Windows, он в поте
лица читает мануалы про то, что это вообще такое есть и как это все
поставить, а тут еще какие-то разделы. :)

У флагов компиляции есть одно преимущество - они играют в том же масштабе
времени. Но процессорное время уместно мерять нано- и микросекундами, а вот
винчестерное, увы, миллисекундами.

За счет этого Reiser4 с плагином сжатия файлов (официально пока не доступен,

к сожалению) на лету работает значительно *быстрее*, чем другие ФС (еще и
место экономит!), ибо для процессора распаковать данные - тьфу, а вот
винчестеру читать - ой-ой-ой. Здесь же накладные расходы еще значительно
меньше.

Именно поэтому то, что Reiser4 используя в два раза больше процессорного
времени (без компрессии), на самом деле, дает нам огромный прирост в общей
скорости работы. Потратив несколько дополнительных микросекунд процессора
мы можем и сокращаем время работы с винчестером на миллисекунды. Винчестеры
чудовищно медленны в сравнении с остальными частями компьютеров.

ИМХО, всему свое время и всему свое применение. Тут вообще, прежде чем
рассуждать о хитрых "катастрофоустойчивых" разбиениях, стоит задать один
простой вопрос - бэкапы-то делаем, али как (это не Вам конкретно, это в
целом :))? Поскольку, если нет, то говорить-то не о чем, винчестеры имеют
свойство дохнуть быстро и целиком, так что хитрые разбивки спасают разве
что действительно от ошибок самих ФС (и, соответственно, имеют смысл тогда,
когда предъявляются настолько жесткие требования по устойчивости системы).

Ну и насчет времени - изучать, а особенно прикидывать это все в самом начале

пути крайне сложно. Learning curve и так довольно крута, не стоит
превращать ее в отвесную стену - не все заберутся. :)

On 06.01.11 10:05, Roman I Khimov wrote:

Ok, сказано достаточно, предлагаю завершить беседу.

С уважением,
vjp7 <vj***@g*****.net>

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 23655; Возраст листа: 901; Участников: 1462
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/499998