Сравнение производительности файловых систем или Reiser4 наносит ответный удар.

> O_DIRECT может помочь в собственном приложении.

_Только_ в случае эксклюзивного доступа к файлу (а лучше даже к partition), иначе вы можете систему на коленки поставить.

В ядре уже давно есть более безопасные вызовы fadvise/madvise.

> один изменённый байт в файле может поменять весь его сжатый образ

Смотря как реализовано сжатие

>jfs это что, на джаве?!

Судя по бенчмаркам то похоже.

P.S. 2birdie некотоырм людям приходится пускать своп через xfs =D

У меня почти 2 года на домашней машине без UPS / -- ext3, /home -- reiserfs

Было черт знает сколько отключений электричества

для ext3 приходилось 2 раза запустить fsck.ext3, с рейзером не случалось ни чего

> jfs это что, на джаве?!

изделие от бимеров, изначально для своих систем (AIX & Co)

> Вполне, только один изменённый байт в файле может поменять весь его сжатый образ, и вам придётся сбрасывать на диск весь файл, вместо одного 1 байта в случае без сжатия.

это только у безграмотных так, в фалухах файл бьют на блоки и жмут их отдельно. Следовательно при изменении одного байта будет пережат только один блок.

> А какую великий алл посоветует ФС для максимально быстрого произвольного доступа (чтение) к одному ну очень гигантскому файлу (сотня и более гигов). Никаких других требований кроме скорости чтения из произвольных мест нет. Сейчас на XFS, но может что получше есть?

Тут XFS лучше всех -- личный опыт подобных игр (весьма интенсивных) за несколько (порядка 5) лет на сотнях серверов в различных режимах:

Сотни тысяч мелких файлов -- вне конкуренции ReiserFS. Несколько (десятки) терабайтных файлов -- вне конкуренции XFS.

Но обе они не шибко надежны. ext2/3 надежнее в разы. ReiserFS слетает постоянно (если у вас не слетало -- поверьте, вам просто повезло!). XFS иногда теряет фрагменты файлов, но разделы на ней ни разу не терял. С ext2/3 просто проблем не было ни разу -- но она и не использовалась столь интенсивно (обычно она у меня просто в качестве файлопомойки выступает).

Да, говорю только про Линуксово-доступные файлухи. JFS не щупал. Всякие AFS и Lustr'ы -- совершенно для других случаев, если кто не въехал.

у меня роутер на рейзере стоял. о том что посыпался винт (хорошо так посыпался) я узнал месяца через 2, когда перестал запускаться ls

javaScript зы: Почти обидел :)

>Да, говорю только про Линуксово-доступные файлухи. JFS не щупал. Всякие AFS и Lustr'ы -- совершенно для других случаев, если кто не въехал.

Всякие RFS4 и XFS совершенно для других случаев, если кто не въехал.

+1

на ext* напрягает долгий чек. Вообще, в последнее время полюбилась иксфс. Для домашней машины - особенно :)

anonymous (*) (06.04.2007 20:53:09):

> Всякие RFS4 и XFS совершенно для других случаев, если кто не въехал.

Я не въехал....

Я так понял, ты просто так, анонимусошумовой фон создаешь, "дух ЛОРа" сгущаешь?

:-)

> на ext* напрягает долгий чек. Вообще, в последнее время полюбилась иксфс. Для домашней машины - особенно :)

какой чек? tune2fs -C 0 <dev>

> В ядре уже давно есть более безопасные вызовы fadvise/madvise.

ага, есть. попробуй перезаписать страницу через mmap. прочитать ее сначала не хочешь?

>>As you can see, REISER4 is a truly remarkable filesystem.
>>This is the real reason that REISER4 has not been included in the Linux kernel.
>>This is the real reason that Hans Reiser languishes in an Oakland prison cell at this time.

>бгг

Бгг уже после "REISER4 is a truly remarkable filesystem".

>Reiser4 уже который месяц не может пройти тестов на включение в ядро. Кому нафиг сплющилась эта производительность? Уж лучше медленне да с данными, чем на ракете в /dev/vagina

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

а я сходив по ссылке получил:
>40 Meg Limit Exceeded!

This site has exceeded its limit of 40 Megabytes of transfer per day. The account can be upgraded to a paid account to increase the transfer limit up to 15 Gigs of transfer per month in your 150m.com user tools section.

If you would like your own 100 MB FREE WEB SITE with a long list of features simply sign up at 150m.com

> Reiser4 с компрессией начнет _очень_ сильно сливать на архивах с картинками, фильмами и уже запаковынными или плохокомпрессируемыми данными.

Не начнет.

Я бы для начала поинтересовался, как там все это работает..

> This site has exceeded its limit of 40 Megabytes of transfer per day

ЛОР-эффект однако :)

> это только у безграмотных так, в фалухах файл бьют на блоки и жмут их отдельно. Следовательно при изменении одного байта будет пережат только один блок.

Согласен, не подумавши сказал.

Ну тут вроде речь шла о скорости а не о недостатках сжатия. Понтно что она не всегда нужно. Но как я помню в reiser4 есть возможность включать сжатие дя конкретных файлов только.

а вот в ext* rdump из отладчика в катастроффмоде позволяет достать многое из файлов при креше. а какова возможность достать данные из райзера и xfs?

>> O_DIRECT может помочь в собственном приложении.

>_Только_ в случае эксклюзивного доступа к файлу (а лучше даже к partition), иначе вы можете систему на коленки поставить.

Насколько я знаю, с блокировками в o_direct все в порядке. Дело не в этом, а в отсутствии накладных page cache.

>В ядре уже давно есть более безопасные вызовы fadvise/madvise.

Эти вызовы не имеют никакого отношения к o_direct - это вызов readahead, при многогигабайтном файле, не помещающемся в ram и page cache, это приведет только к ненужной работе диска.

>> Reiser4 с компрессией начнет _очень_ сильно сливать на архивах с картинками, фильмами и уже запаковынными или плохокомпрессируемыми данными.

>Не начнет.

>Я бы для начала поинтересовался, как там все это работает..

Так исходники же открыты. И тесты от linux journal на медленной машине были - компрессия в reiser4 очень сильно требовательна к типу файла и количеству свободных мегагерц (гигагерц) в процессоре.

>>В ядре уже давно есть более безопасные вызовы fadvise/madvise.

> Эти вызовы не имеют никакого отношения к o_direct - это вызов readahead, при многогигабайтном файле, не помещающемся в ram и page cache, это приведет только к ненужной работе диска.

Эти вызовы фактически и предназначены для управления page cache.

>Эти вызовы фактически и предназначены для управления page cache.

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

Причем даже не управление page cache, а банальный вызов механизма readahead.

> Причем даже не управление page cache, а банальный вызов механизма readahead.

Ну, если MADV_DONTNEED и MADV_WILLNEED - это не управление, тогда ой.

++

Под задачу всё конечно должно подбираться.

А в общих случаях втыкаю что в дистре по дефолту предлагается.

>Ну, если MADV_DONTNEED и MADV_WILLNEED - это не управление, тогда ой.

POSIX_FADV_WILLNEED -> force_page_cache_readahead()

POSIX_FADV_DONTNEED -> invalidate_mapping_pages()

Первая вызывает readahead, вторая помечает страницы, которые _возможно_ будут сброшены, а возможно и нет. Удаление страниц из page cache произойдет заметно позже.

Так что нет, функции *advice() не управляют page cache, а позволяют вызвать readahead, который в свою очередь добавит накладных расходов.

Хотя Линус и не любит o_direct, это весьма полезная особенность.

Для тех, кто считает, что компрессия - это хорошо:

Gzip - 3 files (zeros only, raw DV data from video camera, x86_64
kernel rpm file), 10 MB of data (10*1024*1024), done on tmpfs so no
real disk speed factor. The CPU is AMD64 with 1 MB cache per core,
2600 MHz clock (clock scaling disabled). That's my typical usage
pattern (well, not counting these zeros).

$ l -Ggh zeros dv bin
-rw-r--r-- 1 10M Apr  7 15:30 bin
-rw-r--r-- 1 10M Apr  7 15:31 dv
-rw-r--r-- 1 10M Apr  7 15:31 zeros

$ for f in zeros dv bin; do time gzip $f; done
real    0m0.112s
real    0m0.686s
real    0m0.559s

Dealing with pure zeros gzip can get almost 90 MB/s compressing, but
with DV and rpm it only does 14.5 and almost 18 MB/s respectively...

$ l -Ggh zeros.gz dv.gz bin.gz
-rw-r--r-- 1  10K Apr  7 15:31 zeros.gz
-rw-r--r-- 1 9.1M Apr  7 15:31 dv.gz
-rw-r--r-- 1 9.3M Apr  7 15:30 bin.gz

... and though the numbers may still sound impressive, space savings
are less than 10%.

$ for f in zeros dv bin; do time gunzip $f.gz; done
real    0m0.067s
real    0m0.131s
real    0m0.120s

Decompression gives 150 MB/s for zeros and ~ 80 MB/s for DV and rpm.

$ for f in zeros dv bin; do time gzip -1 $f; done
real    0m0.079s
real    0m0.572s
real    0m0.530s

Supposed to be "fastest gzip". 126 MB/s for zeros but still less than
19 MB/s for DV and rpm.

$ l -Ggh zeros.gz dv.gz bin.gz
-rw-r--r-- 1  45K Apr  7 15:31 zeros.gz
-rw-r--r-- 1 9.2M Apr  7 15:31 dv.gz
-rw-r--r-- 1 9.3M Apr  7 15:30 bin.gz

$ for f in zeros dv bin; do time gunzip $f.gz; done
real    0m0.044s
real    0m0.135s
real    0m0.120s

It seems gzip can decompress zeros with 227 MB/s rate.
I assume the "4x read speed" claim comes from something like this.

$ /sbin/hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  210 MB in  3.02 seconds =  69.59 MB/sec

$ echo "69.59*4" | bc
278.36

Seems you'd need a faster algorithm, faster machine or slower disk
- slower than this cheap SATA with disabled NCQ (NV SATA) at least:

$ cat /sys/block/sda/device/model
Maxtor 6V250F0

Please note that application-level compression usually gives way
better results - the application knows much more.


Для тех, кто ниасиливает аглицкие буквы - там сказано, что бинарные данные с выхода камеры и rpm сжимаются очень плохо, и такие тесты дают заметно меньший выигрыш в используемом месте и скорости диска. Скорость же чтения (декомпрессирования DV и rpm) порядка 20мб, что в 3 раза меньше скорости чтения с диска, так что выигрыша нет вообще.

> Удаление страниц из page cache произойдет заметно позже.

Если я правильно понимаю код в mm/madvise.c, удаление произойдет _немедленно_ (zap_page_range). Хотя это overkill, ИМХО.

> Так что нет, функции *advice() не управляют page cache, а позволяют вызвать readahead

Или отказаться от него, указав MADV_RANDOM. Итого: включение/выключение readahead, сброс page cache. Это управлением не считается?

>> Удаление страниц из page cache произойдет заметно позже.

>Если я правильно понимаю код в mm/madvise.c, удаление произойдет _немедленно_ (zap_page_range). Хотя это overkill, ИМХО.

Только в некоторых случаях. Check invalidate_complete_page() and remove_mapping().

>> Так что нет, функции *advice() не управляют page cache, а позволяют вызвать readahead

>Или отказаться от него, указав MADV_RANDOM. Итого: включение/выключение readahead, сброс page cache. Это управлением не считается?

Нет, не считается. Управление, это когда делается то, что запрашивается, а для page cache это выполняется только в некоторых случаях.

В любом случае, если бы это было действительно эффективно всяческие oracle не работали бы с raw devices.

> Только в некоторых случаях. Check invalidate_complete_page() and remove_mapping().

только в случае, если страница залочена, записывается или замаплена. последние два случая разрешаются через msync() и madvise(). после которых встретить на странице PG_locked весьма непросто.

резюмируя, неплохой такой контроль над pagecache.

> В любом случае, если бы это было действительно эффективно всяческие oracle не работали бы с raw devices.

не нужно отсылать далеко. лучше честно скажите чего в mmap не хватает.

> Check invalidate_complete_page() and remove_mapping().

не увидел ничего, что противоречило бы моим словам. >>включение/выключение readahead, сброс page cache. Это управлением не считается?

>Нет, не считается. Управление, это когда делается то, что запрашивается, а для page cache это выполняется только в некоторых случаях.

/me вспоминает тред о безопасности Java и решает перестать спорить.

> если бы это было действительно эффективно всяческие oracle не работали бы с raw devices

Исторические причины + ядра до 2.6.x такого не поддерживали.

>> В любом случае, если бы это было действительно эффективно всяческие oracle не работали бы с raw devices.

>не нужно отсылать далеко. лучше честно скажите чего в mmap не хватает.

mmap работает через page cache - представь, что есть 4гб памяти и 50гб файл, readahead для каждой страницы случайного доступа будет выкачивать до 128 страниц, которые затем будут удаляться из page cache, т.к. не используются.

Проблема не в mmap как таковом, а в ненужности накладных расходов для page cache.

>> Check invalidate_complete_page() and remove_mapping().

>не увидел ничего, что противоречило бы моим словам.

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

Напомню первоначальный вопрос:

>>А какую великий алл посоветует ФС для максимально быстрого произвольного доступа (чтение) к одному ну очень гигантскому файлу (сотня и более гигов). Никаких других требований кроме скорости чтения из произвольных мест нет.

И ответ на него, что o_direct может помочь. А *advice() ситуацию не сильно спасет, т.к. доступ произвольный, и будут только пустые накладные расходы из-за readahead.

Спорить нужно о том, о чем начинали. Касательно же управления page cache - это не верно хотя бы потому, что доступ и удаление страниц не контроллируется из posix_fadvise(), а подчиняется (в первую очередь) нагрузкой на VFS, и только во вторую - _советом_ пользователя. Так же page cache содержит данные всех файлов, к которым осуществляется доступ, а не только тех, которые нужны (т.е. если у вас два огромных файла, к которым постоянно идет доступ, *advice() будет выкидывать чужие страницы, которые тут же будут возвращаться, выкидывая только что прочитанные.

А вот, что думал автор об posix_fadvice() изначально:


  This can be used for providing the kernel hints about desired readahead
  patterns, and for launching asynchronous readahead (what sys_readahead
  does).

  But its main application is for program-directed freeing of pagecache
  against large streamed files. This is what O_STREAMING gives, only
  posix_fadvise() is harder to use, less efficient and standards-based. 

Т.е. идея-то была корректна, но

 * invalidate_mapping_pages() will not block on IO activity. It will not
 * invalidate pages which are dirty, locked, under writeback or mapped into
 * pagetables.

Т.е. если кто-то записал данные в страницу, она не будет выброшена из page cache, и не будет записана на диск. А именно это и делает тот, кто первоначально спросил о файловой системе для записи в _произвольные_ места огромного файла.

Про залоченные страницы и так ясно.

> mmap работает через page cache - представь, что есть 4гб памяти и 50гб файл, readahead для каждой страницы случайного доступа будет выкачивать до 128 страниц, которые затем будут удаляться из page cache, т.к. не используются.

read-ahead можно отключить. "прикиньда?"

> Проблема не в mmap как таковом, а в ненужности накладных расходов для page cache.

и каждый раз при direct I/O проверять pagecache на наличие страниц (чтобы алиасы убить), иметь второй механизм (корявый) и проч. - это "нужный накладной расход" ? не шибко убедительно.

> Т.е. если кто-то записал данные в страницу, она не будет выброшена из page cache, и не будет записана на диск. А именно это и делает тот, кто первоначально спросил о файловой системе для записи в _произвольные_ места огромного файла.

еще раз читаем про msync (который сделает страницы чистыми) и madvise (который их выкинет из pgtable).

> Про залоченные страницы и так ясно.

не поделитесь что именно ясно? :)

>read-ahead можно отключить. "прикиньда?"

И о чем речь, помните? Я и говорю, что для заданного сценария доступа readahead не нужен как класс, а следовательно *advice() никак не помогут.

>> Проблема не в mmap как таковом, а в ненужности накладных расходов для page cache.

>и каждый раз при direct I/O проверять pagecache на наличие страниц (чтобы алиасы убить), иметь второй механизм (корявый) и проч. - это "нужный накладной расход" ? не шибко убедительно.

Если доступ к файлу только через o_direct - накладных нет вообще. Человеку не нужен дополнительный кэш - ему нужны только данные из произвольных участков огромного файла.

> Так же page cache содержит данные всех файлов, к которым осуществляется доступ, а не только тех, которые нужны (т.е. если у вас два огромных файла, к которым постоянно идет доступ, *advice() будет выкидывать чужие страницы, которые тут же будут возвращаться, выкидывая только что прочитанные.

милай, ты что курил?

madvise() работает в контексте конкретного пространства адресов: sys_madvise() -> madvise_vma() -> madvise_dontneed() -> zap_page_range() ...

следовательно грохнет только те файлы, которые замаплены на твои страницы.

fadvise() работает аналогично в пределах одной иноды: sys_fadvise64() -> sys_fadvise64_64() -> invalidate_mapping_pages()

по-моему господин рассчитывал, что все читатели LOR'а идиоты.

> Cтранный подход - сначала говорить об одном, а затем плавно переходить на другую тему

В нашем с вами разговоре обсуждались средства управления page cache и readahead, и ничего больше.

> Если доступ к файлу только через o_direct - накладных нет вообще. Человеку не нужен дополнительный кэш - ему нужны только данные из произвольных участков огромного файла.

есть проверка на наличие страниц в pagecache. сам найдешь? перестань уже мыслить в дебильных терминах "дополнительного кэша". какая тебе разница какая страница: в анонимном маппинге или инодном?

>> Т.е. если кто-то записал данные в страницу, она не будет выброшена из page cache, и не будет записана на диск. А именно это и делает тот, кто первоначально спросил о файловой системе для записи в _произвольные_ места огромного файла.

>еще раз читаем про msync (который сделает страницы чистыми) и madvise (который их выкинет из pgtable).

Да, для mmap подходит, для файлового дескриптора - нет, fsync и прочие сбрасывают все страницы. И это опять дополнительные накладные расходы.

>> Про залоченные страницы и так ясно.

>не поделитесь что именно ясно? :)

Ваша ирония не к месту.

> Так исходники же открыты.

Так заглянуть бы надо туда, прежде чем думать, что фс покорно будет сжимать все подряд. > И тесты от linux journal на медленной машине были - компрессия в reiser4 очень сильно требовательна к типу файла и количеству свободных мегагерц (гигагерц) в процессоре.

А еще есть тесты, демонстрирующие отстойную производительность, когда большие файлы хранятся не в экстентах, а во фрагментах. Давайте покажем на них пальцем, но от этого reiser4 не перестанет делать tail conversion . То же самое и с компрессией. Все настраивается. Можете добавить свой плагин, который смотрит на свободные герцы..

> Да, для mmap подходит, для файлового дескриптора - нет, fsync и прочие сбрасывают все страницы. И это опять дополнительные накладные расходы.

чего? msync() сбрасывает только нужные страницы. какие еще накладные расходы?

> Ваша ирония не к месту.

до тех пор пока не объясните - очень даже к месту.

>madvise() работает в контексте конкретного пространства адресов: sys_madvise() -> madvise_vma() -> madvise_dontneed() -> zap_page_range() ...

>следовательно грохнет только те файлы, которые замаплены на твои страницы.

>fadvise() работает аналогично в пределах одной иноды: sys_fadvise64() -> sys_fadvise64_64() -> invalidate_mapping_pages()

Почитайте еще раз, о чем шла речь выше - readahead, вызванный fadvise(), запустит swapper/bdflush, которые выкинут из кэша чужие страницы, следующий readahead - для другого файла, выкинет страницы первого (в своп или на диск).

Так и зачем он нужен? Правильно, readahead не нужен. А page cache зачем в этой задаче случайной выборки страниц?

>по-моему господин рассчитывал, что все читатели LOR'а идиоты.

Далеко не все, но вы слишком высокого мнения о себе и низкого о других.

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

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

>>И тесты от linux journal на медленной машине были - компрессия в reiser4 очень сильно требовательна к типу файла и количеству свободных мегагерц (гигагерц) в процессоре.

>А еще есть тесты, демонстрирующие отстойную производительность, когда большие файлы хранятся не в экстентах, а во фрагментах. Давайте покажем на них пальцем, но от этого reiser4 не перестанет делать tail conversion . То же самое и с компрессией. Все настраивается. Можете добавить свой плагин, который смотрит на свободные герцы..

У администратора нет возможности писать свой плагин, ему проще отключить это свойство.

> Так и зачем он нужен? Правильно, readahead не нужен. А page cache зачем в этой задаче случайной выборки страниц?

затем, что это один универсальный механизм, а не корявый костыль direct IO. еще раз, анонимные страницы - это по-сути тот же pagecache, только backing device для него - swap, а не инода того файла, с которым работаем.

> Почитайте еще раз, о чем шла речь выше - readahead, вызванный fadvise(), запустит swapper/bdflush, которые выкинут из кэша чужие страницы, следующий readahead - для другого файла, выкинет страницы первого (в своп или на диск).

бугога. а аллокация анонимных страниц, в которые потом будет класть directIO этого не вызовет? бугога.