какая вообще разница на чём корень?
[Ъ]в него пишется раз в пол года.[Ъ]

в целом рейзер 3.6 всё ещё неплох, при определённых настройках (менее безопасных) и ext4 ничего.
Лучше всего смотреть на фороникс, если там всё прочитать, то картинка более-менее вырисовывается. Главное - не реагировать на их выводы и читать внимательно условия тестов.

Открой mc /usr/lib или запусти firefox - узнаешь какая )

+ в догонку вопрос:

# hdparm -t /dev/sda3
/dev/sda3:
 Timing buffered disk reads:  116 MB in  3.02 seconds =  38.35 MB/sec

# hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:  228 MB in  3.02 seconds =  75.48 MB/sec

root@msy:~# ldd /usr/bin/midori | grep -v /usr | wc -l
15
root@msy:~# 

из за 15ти файлов менять ФС? =) красноглазие ради красноглазия.

>midori

Не-не-не Девид блейн:

# ldd /usr/lib/libwebkit-1.0.so |wc -l 
68

Да, вспоминая предыдущие разговоры с вами КО поясняет:

midori использует webkit.

следим за руками, внимательно..

root@msy:~# ldd /usr/bin/midori | wc -l
75
root@msy:~# 

root@msy:~# ldd /usr/bin/midori | grep -v /usr | wc -l
15
root@msy:~# 

>разных слайсах.

Те разные разделы, но на одном hdd?
И какой прирост скорости запуска?

Я тебя огорчу, но hdparm -t пофигу какая там фс, он тестирует блочное устройство.

Впрочем, 90% либ и ресурсов прог и так в /usr, разве что /usr/{bin,lib,share} поместить на разные разделы?

Так в чём дело-то?

>Те разные разделы, но на одном hdd?
слайс == раздел, я просто слово «раздел» с утра не вспомнил без кофе.

И какой прирост скорости запуска?

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

если нужны тесты, советую сделать блочное устройство в файле, гигов на 5.
а потом форматнуть его в ext4 и промерять скорость чтения от туда.
именно чтения, и так сравнить.

погрешность будет минимальная.

>о безопасности при сбоях.

В топике вопрос не об этом %)

А вам не кажется, что XFS медленновата? У самого XFS только на USB-HDD, чтобы в мастдае было сложнее подмонтировать (хотя, оказалось, и XFS в мастдае можно запустить); на всех разделах reiser (да, да, обычный старый добрый reiserfs).

Потестить пока не могу, но судя по линку в топике это не совсем так.

Многие результаты тестов по этой вашей ссылке - в пределах погрешности. Лучше, все-таки, сделать тест самостоятельно (причем не на монтирование/отмонтирование, а на запись/чтение файлов - крупных и мелких, время полной проверки fsck).

Понятно.
Что скажете насчёт этого:
http://www.linux.org.ru/jump-message.jsp?msgid=5308312&cid=5308364 ?

У вас, наверное, появилась активность на HDD в момент проведения первого теста.

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   1760 MB in  2.00 seconds = 880.08 MB/sec
 Timing buffered disk reads:  186 MB in  3.01 seconds =  61.80 MB/sec
[ROOT SESSION 07.09 09:06 /home/change/345]
hdparm -tT /dev/sda1

/dev/sda1:
 Timing cached reads:   1722 MB in  2.00 seconds = 861.24 MB/sec
 Timing buffered disk reads:  186 MB in  3.01 seconds =  61.82 MB/sec

Сейчас сделаю простенький тестик (с 20Гб файлом, через loop-device).

Странно, прибил практически все процессы, повторял несколько раз - то же самое.
Может ли быть проблема в выравнивании разделов?

> Так в чём дело-то?
Просто указание на тип фс в контексте hdparm -t как-бы бессмысленно.
sda3 находится далеко от начала диска?

Может ли быть проблема в выравнивании разделов?

Да

Отлично, выхлоп фдиска в посте выше, какая инфаормация ещё нужна?

>Там нет ext4

Значит, сравнение страшно устарело :) ext4 - одна из лучших сегодняшних FS.

Сейчас / и /home на XFS.

xfs в /home - это плохо. У неё чрезвычайно медленное удаление. А для /home это критично.

xfs хороша на разделах, которые при работе обычно используются только для чтения (тот же /usr). И незаменима там, где требуется дефрагментация (например, всякие p2p закачки).

А, ну тогда это нормально. У меня тоже примерно также скорость падает к концу винта.

nao@alpha:~  $ sudo hdparm -t /dev/sda1

/dev/sda1:
 Timing buffered disk reads:  224 MB in  3.01 seconds =  74.34 MB/sec
nao@alpha:~  $ sudo hdparm -t /dev/sda6

/dev/sda6:
 Timing buffered disk reads:  106 MB in  3.01 seconds =  35.26 MB/sec
nao@alpha:~  $ sudo hdparm -tT /dev/sda1

(sda6 в конце винта)

Отлично, сношу венду.

reiserfs

1Гб файл

Создание: 20-21с

Чтение: 18-19с

Удаление: 0.36-0.37с

1000 файлов по 1Мб

Создание: 21-22с

Чтение: 21-22с

Удаление: 0.36-0.38с

10Гб файл

Создание: 4 минуты 4 секунды

Чтение: 3 минуты 8 секунд

Удаление: 3.26с

Далее ограничусь лишь 1Гб и 1000 по 1Мб, т.к. операции с 10Гб файлом происходят уж слишком долго.

# hdparm -t /dev/sda1
/dev/sda1:
 Timing buffered disk reads:  216 MB in  3.01 seconds =  71.81 MB/sec

Отлично! Я нуб.

XFS

1Гб файл

создание: 20-21с

чтение: 18-19с

удаление: 0.03-0.04с

1000 файлов по 1Мб

создание: 23-25с

чтение: 19-21с

удаление: ~2с

Спасибо! Пожалуй оставлю таки xfs. </thread>

Отлично! Я нуб. странные выводы =) вообще-то, как гласит ДАО, прежде чем оптимизировать, нужно найти узкое место. думаю что если проблемы возникаю при запуске некого ПО (ФФ), то сомневаюсь что узкое место это файловая система или положение раздела =)

root@msy:~# hdparm -t /dev/sda1 
 
/dev/sda1: 
 Timing buffered disk reads:  168 MB in  3.03 seconds =  55.39 MB/sec

 
root@msy:~# hdparm -t /dev/sda8

/dev/sda8: 
Timing buffered disk reads: 156 MB in 3.01 seconds = 51.76 MB/sec root@msy:~# 

Я эти проблемы решил переходом на хром и установкой preload, но хочется соптимизировать «на полную».
Да и раздел в начале hdd у меня значительно быстрее, чем в конце (ноутбучный hdd).

EXT4

1Гб файл

создание: 18-20с

чтение: 19-20с

удаление: 0.06-0.08с

1000 по 1Мб

создание: 19-20с

чтение: 20-21c

удаление: ~0.1c

ext4 выходит производительнее...

А покажите ещё ваш вывод fdisk -ul /dev/sda пожалуйста

Мне важнее скорость чтения. Хотя, подумаю.

А покажите ещё ваш вывод fdisk -ul /dev/sda пожалуйста

root@msy:~# fdisk -ul /dev/sda

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1   156301487    78150743+  ee  GPT
root@msy:~# 

Еще не стоит забывать, что XFS отлично оптимизирована под параллельное IO — в этом с ней ни одна из популярных ФС тягаться не может.
Но хранить на ней какие-то данные, более важные, нежели прон, и в которые при этом может идти запись, категорически противопоказано по известной причине.

>ext4 выходит производительнее...

А что будет, если синхронно запускать по десятку таких тестов? :)

ext4 порадовала; новый винт интереса ради под ней завел, очень шустрая.

Под xfs живет старый раздел с фильмами, не нарадуюсь. но мелкие файлы на нее складывать не рекомендуется.

Вот именно. Для надежности - проверенная временем reiserfs, для скорости - ext4.

А что будет, если синхронно запускать по десятку таких тестов? :)

Хотите - попробуйте. Мне пора поработать.

Ах, GPT, ну тогда уж партедом покажите наконец что там внутри :)

Вот так и появляются те, кто говорит «ваш линупс тормозный, у меня в венде скорость - ВО ^, а в линупсе скорость - во _!»

как то так

root@msy:~# parted -l
Model: ATA ST380011A (scsi)
Disk /dev/sda: 80,0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17,4kB  300MB   300MB   ext3
 2      300MB   800MB   500MB   ext4
 3      800MB   9800MB  9000MB  ext4
 4      9800MB  13,8GB  4000MB  ext4
 5      13,8GB  14,8GB  1000MB  ext4
 6      14,8GB  14,9GB  100MB   reiserfs
 7      14,9GB  15,1GB  200MB   reiserfs
 8      15,1GB  80,0GB  64,9GB  ext4

>Для надежности - проверенная временем reiserfs

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

для скорости - ext4.

Для скорости, если речь не идет о регулярном удалении большого количества файлов, я бы все-таки рекомендовал XFS.
Именно потому, что очень часто сразу несколько процессов интенсивно работают с файловой системой. Преимущества остальных ФС сохраняются только когда такой процесс один.

>Хотите - попробуйте. Мне пора поработать.

Как ни парадоксально, мне тоже :)
Это просто был намек на некоторую искусственность тестов в один поток.

xfs_adm

-c 0|1 Enable (1) or disable (0) lazy-counters in the filesystem. This operation may take quite a bit of time on large filesystems as the entire filesystem needs to be scanned when this option is changed.

With lazy-counters enabled, the superblock is not modified or logged on every change of the free-space and inode counters. Instead, enough information is kept in other parts of the filesystem to be able to maintain the counter values without needing to keep them in the superblock. This gives significant improvements in performance on some configurations and metadata inten- sive workloads.