> neko@ezhik

Няка на ежике. Этим всё сказано.

покрути опции монтирования

$ time pacman -Ss kernel26
<skip>
real    0m1.525s
user    0m0.903s
sys     0m0.610s
$ mount | grep '/ '
/dev/sda3 on / type ext4 (rw,relatime,barrier=1,data=ordered)

PS нетбук

...core/zd1211-firmware 1.4-4
Firmware for the in-kernel26 zd1211rw wireless driver
^C^C^C^C

real 1m29.248s

и еще, например -
[neko@ezhik ~]$ pacman -Suy
:: Синхронизируются базы данных пакетов...
core не устарел
extra не устарел
community не устарел
archlinuxfr не устарел
catalyst не устарел
:: Запускается полное обновление системы...

вот так уже полминуты висит

кстате - второй раз что pacman -Suy что pacman -Ss проходят почти мгновенно.
real 0m0.417s

> Няка на ежике.
Не няка, а неко, то бишь кошко.

Этим всё сказано.

И вообще, оффтопик.

ext4 - почему оно такой тормоз?

Фрагментация?

фс создана день назад, какая нахрен фрагментация? >_>

>> кстате - второй раз что pacman -Suy что pacman -Ss проходят почти мгновенно.

Read cache.

[neko@ezhik ~]$ filefrag /var/lib/pacman/*db*
/var/lib/pacman/archlinuxfr.db.tar.gz: 1 extent found
/var/lib/pacman/catalyst.db.tar.gz: 1 extent found
/var/lib/pacman/community.db.tar.gz: 1 extent found
/var/lib/pacman/core.db.tar.gz: 1 extent found
/var/lib/pacman/extra.db.tar.gz: 1 extent found

> фс создана день назад
Ты этого не упоминал, или я что-то пропустил?

ды я понял что оно кэш, но почему на рейзере без всякого кэша (т.е. первый запуск) пакман летал, а на ехт4 с дефолтными опциями монтирования apt на дебиане летал так же как и пакман на рейзере? (т.е. ничуть не тормозил)

[code]
[neko@ezhik ~]$ echo 1 | sudo tee /proc/sys/vm/drop_caches && sync
Пароль:
[neko@ezhik ~]$ time pacman -Ss kernel26
...
real 0m42.756s
user 0m0.553s
sys 0m0.893s
[neko@ezhik ~]$
[/code]

_<

ext4 не любит много мелких файлов. На гентушных портежах он тоже тормозит

fs ext4

>очему на рейзере без всякого кэша (т.е. первый запуск) пакман летал, а на ехт4 с дефолтными опциями монтирования apt на дебиане летал так же как и пакман на рейзере?

А apt'а и pacman'а база данных хранится на диске по-разному. У pacman — это куча мелких файликов (на каждый пакет, имеющейся в репах — несколько текстовых файлов, можешь глянуть в /va/lib/pacman/sync), причем совсем мелких, запросто может быть меньше 100 байт; отсюда и тормоза при чтении. У apta информация о пакетах хранится в нескольких файлов, в одном файле, ЕМНИП, инфа сразу о куче пакетов (файлы тоже текстовые). Считать несколько крупных файлов — это быстрее (в общем случае), чем тысячи мелких, даже если их суммарные размеры равны.

ReiserFS как раз и славился тем, что он быстр при работе с кучей очень маленьких файлов (особенно, если не включать явным образом опцию notail), его ещё раньше рекомендовали для хранения на нем дерева портежей в gentoo.

Их, по-моему, никто кроме рейзера и не любит.

и чт самое интересное -
# pacman -Ss kernel26
совпадения из репо core' оно отображает мгновенно, а остальное - думает полминуты...

>ReiserFS как раз и славился тем, что он быстр при работе с кучей очень маленьких файлов (особенно, если не включать явным образом опцию notail)
ты опять всё перепутал
notail как раз ускоряет - на записи
а на чтении он вообще не имеет значения

# pacman-optimize && sync

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

>relatime
может стоит заменить на noatime,nodiratime?
или так нужно время последнего доступа к файлу/дире?

эм..
apt
pacman на reiser3.6
// pacman-optimize делал. эффекта - ноль целых хер десятых.

да какая разница?
переносил pacman database на /home
тут вообще
/dev/sda2 on /home type ext4 (rw)
никаких опций. все такой ж тормоз.

подумай что происходит с relatime/atime при чтении тысяч файлов...

> apt

ви делаете мне смищно.
эта штука будет тормозить всегда везде, карма у нее такая.

reiser3.6

с фрагментацией на нем как принято бороться? Где-то на глаза попадалось (кажется тут же, на ЛОРе), что он довольно быстро деградирует.

Мб, давно с рейзером дела не имел, мог и забыть.

омг.
создал reiserfs на обыкновенном файле (100мб)
смонтировал в /mnt и кинул базу туда
[neko@ezhik ~]$ su -c 'echo 1 > /proc/sys/vm/drop_caches' && sync
[neko@ezhik ~]$ time pacman -Ss kernel26
real 0m1.177s
user 0m0.257s
sys 0m0.247s

ну выходит так :)
notail отключает же упаковку «хвостов» - а это время

С relatime при чтении — ничего.

>с фрагментацией на нем как принято бороться? Где-то на глаза попадалось (кажется тут же, на ЛОРе), что он довольно быстро деградирует.

надо же, 5 лет стоит и я не замечал этого. видимо, я вместе с райзером деградирую

почитай вот этот пост http://www.linux.org.ru/jump-message.jsp?msgid=5491264&cid=5501960
и вот этот http://www.linux.org.ru/jump-message.jsp?msgid=5491264&cid=5502053
сравни цифры при работе с кучей мелких файлов (дерево портажа) с noatime,nodiratime
и без

ну не надо тут )
таки relatime ведёт себя не так же, как noatime

man mount

       relatime
              Update  inode  access  times  relative to modify or change time.
              Access time is only updated if the previous access time was ear‐
              lier  than  the current modify or change time. (Similar to noat‐
              ime, but doesn't break mutt or other applications that  need  to
              know  if  a  file has been read since the last time it was modi‐
              fied.)

>с фрагментацией на нем как принято бороться?

ему на нее пох, чем больше беспорядка, тем быстрее работает :)

> надо же, 5 лет стоит и я не замечал этого. видимо, я вместе с райзером деградирую

эпик фейлов не было?
как оно относится к внезапному оффлайну?

>как оно относится к внезапному оффлайну?
отлично

Переехать что-ли. Меня уже тоже порядком утомили тупняки ext4, причем далеко не на нетбуке.

и?

>> эта штука у меня будет тормозить всегда везде, карма у меня такая.

Не мог не поправить.

>как оно относится к внезапному оффлайну?
ему похер абсолютно - даже во время записи

Отлично. Осталось два вопроса:
первый - 3 или 4?
второй - как там обстоит дело с шифрованием, dm-crypt выкинуть можно?

>> первый - 3 или 4?

Только 3.

как там обстоит дело с шифрованием

Никак.

3
шифрования своего нету
но: у меня после года использования на ноуте начались с(т)ран(н)ые утечки памяти.
то есть -
# echo i > /proc/sysrq-trigger
# free
... used
...
-/+ buffers/cache: 500
т.е. 500мб занято, но мы послали SIGKILL всем процессам.
# mount -o remount /
# mount -o remount /home
# free
... used
... 20
т.е. после remount'а занято 20 мб (до него - 500)

> Только 3.

Поделись причинами такой категоричности?

Никак.

Вроде же было что-то встроенное? Или это только в четверке?

только в четверке.
reiser4 _очень_ нестабильна

хм...не наблюдал такого

только 3
шифрования своего нет

> только в четверке.

reiser4 _очень_ нестабильна

Эх, жаль... я так мечтал избавиться от однопоточного dm-crypt...