xfs -> reiserfs - это ПЯТЬ!

К сожалению, нет. Ext3 пока ничего не теряла просто так, в отличие от.

/boot таки лучше делать и в фстаб его совсем не прописывать, либо ридонли.

> Не всегда и не везде.

ну в /etc парочка файлов типа mtab и наподобие должна быть rw, но это легко обходится линками.

Вообще говоря, XFS штука очень критичная к железу, как я понял. Есть у нас на работе несколько компов, и там если поставить систему на XFS - практически сразу же при интенсивном I/O винты начинают валиться (soft_reset, hard_reset, и понеслась...). Данные при этом правда остаются целы. С другими FS эта проблема железа не проявляется. Но мне вот очень интересно понять - почему?

> А чем сильно политика на / будет отличаться от политики на /usr? Там тоже особо нечего бекапить, менять и т.п. Только разве /etc, но делать его резервные копии нет никакой проблемы по фактам изменений (которые в идеале вообще не должны быть).

Это, наверное, справедливо, кроме, может быть, atime'а, который на / знать всё же имеет смысл.

Кроме того, я против деления / и /home. Тут нужен минимум ещё /var и /tmp, ну и swap по вкусу.

Ну скажи зачем /tmp в отдельный раздел?

$ sudo du -s /tmp
176 /tmp

ему вообще сейчас место в tmpfs

Всё уже давно приучено какать по крупному в /var/tmp, а вот /home полезнее всё-таки делать.

$ du -hs /tmp
162M /tmp

ы?

>Опера грузится за 4 секунды с нуля (против старых ~20), GIMP - 5 секунд с нуля, OOWrite2.2 - 10 секунд...

А проц/оператива/opera = какой/сколько/какая?

Спрашиваю потому, что у меня, на ext3.

Opera - 3

OOWriter - 4 сек.

Gimp - 2 сек.

Аж страшно менять!

Тут (если верить, сравнениям), думать будет ОПАСНО!

Само запустится.

> ы?

И что?

Cразу ещё до кучи показал бы выхлоп grep tmp /etc/fstab

du -hs /var/tmp покажи лучше, сравним :)

$ grep tmp /etc/fstab
$ sudo du -hs /var/tmp
5,0M /var/tmp

>Ну скажи зачем /tmp в отдельный раздел?

На сервере в отдельный раздел стопудово нужно. Вот сейчас мне накидали картинок каких-то, ресайз которых через imagemagick вызывает появление временных файлов в /tmp на 3.2Гб каждый. Такая DOS-атака :)

>Gimp - 2 сек.

Ой, не верю! :)

>Я упорно не понимаю зачем выносить /usr в отдельный раздел. Хоть убейте.

man mount :)

>А так сложно догадаться ? Для Read Only. Ибо / в RO низзя - там /etc

ну, в принципе, наверное, и / в ro можно, если с /etc поковыряться и конфиги, требующие изменений вынести куданить в /home ... :)

Специально проверил.

Тут, не совсем верно, т.к. тормознул крестом закрыть (где-то - секунды полторы).
~$ time gimp

real    0m4.700s
user    0m1.236s
sys     0m0.196s

> Правда, нагрузка будет ещё выше.

Ой. Тогда не буду переходить на LVM. Для меня загрузка ЦП критична.

>Специально проверил.

Вот это уже больше похоже на истину. Кстати, старт честно холодный?
И какая версия?

2.4rc2

Холодный (сегодня не запускал):

balancer@balpc ~ $ time gimp

real    0m6.165s
user    0m3.517s
sys     0m0.363s

Сразу за ним, тёплый:
balancer@balpc ~ $ time gimp

real    0m4.554s
user    0m3.594s
sys     0m0.296s

Постарался не щелкать клювом =))))

$ time gimp

real    0m4.832s
user    0m1.216s
sys     0m0.208s
$ time gimp

real    0m2.579s
user    0m1.172s
sys     0m0.196s


Но тут еще реакция мышью, ...........

Визуально, считая - 2-3 сек (двадцать один и т.д)

$ time gimp -v
Версия GIMP 2.2.13

real    0m0.007s
user    0m0.004s
sys     0m0.000s

$ uname -a
Linux nickolay 2.6.18-5-686 #1 SMP Thu Aug 30 02:19:07 UTC 2007 i686 GNU/Linux

Правдя, на AMD X2 64

Но, это тем более прикольно, что не оптимально!

>Версия GIMP 2.2.13

Возможно, в этом ещё дело. Как я писал:

gimp -v GNU Image Manipulation Program версии 2.4.0-rc2

...

Вообще, не понимаю, как на 2.2.x можно сидеть. Оно же совершенно неюзабельное :D Я больше года уже только на 2.3.x ветке сидел.