Сравнение файловых систем

>А не лучше ли под mod_deflate процессор запользовать? И за трафик меньше платить, кстати.

Можно, но не факт это эффективнее для сервера. А на счёт траффика - это уже с загрузкой сервера не связано и всеми клиентами поддерживается AFAIK.

>И если уж идет упор в дисковый I/O - всегда есть squid в режиме http accelerator - он в разы эффективней.

Итого - куча инструментов, вместо одного chattr c file:)

>$ ls -l /etc/samba/smb.conf -rw-r--r-- 1 root root 698 Дек 4 23:13 /etc/samba/smb.conf

$ ls -l /etc/samba/smb.conf

-rw-r--r-- 1 root root 18997 Май 27 2005 /etc/samba/smb.conf

И это не сервер:) Да smb.conf я привёл лишь как пример в ответ на ваше "конфиги читаются только раз":)

>Ядро собирается порядка 20 минут (с нуля)

Да ну?!:)

>Соответственно, реальный I/O там 10 мегабайт в минуту - 180 килобайт в секунду

Да неужели?!:)

Среднюю загрузку CPU при сборке большого проекта на C (того же ядра, напрмер) уже проверили?:)

> Замечательно.

Слив засчитан. Мне фиолетово что там греется и кому это нужно, уж вас то я слушать точно не буду. Мавр сделал свое дело, мавр может уходить. Счасливо оставаться.

> Среднюю загрузку CPU при сборке большого проекта на C (того же ядра, напрмер) уже проверили?

Да. 90% user. И вы еще прежлагаете включить компрессию и подрезать процессор всякими переключениями контекста, ломать ему конвееры и так далее?

> $ ls -l /etc/samba/smb.conf
> -rw-r--r-- 1 root root 18997 Май 27 2005 /etc/samba/smb.conf

"Камменты зажыгают"? :-) Самба делает один форк на одного клиента. У вас клиенты на сумбу прут коннектами так, что I/O на smb.conf стал узким местом??? А это ничего, что оно на форка убъется задолго до этого?

> Итого - куча инструментов, вместо одного chattr c file

сквид как специализированный инструмент отдает статический контент в разы быстрее, просто потому, что он все что можно в своем собственном кэше держит и на диск вообще не обращается, если только есть такая возможность. И какое бы сжатие ты не включал, скорость работы с памятью ты не перекроеш (это от полутора гигабайт в секунду). И если у тебя канал 100 мегабит, никакое сжатие на ФС не позволит тебе отдать больше 12 мегабайт в секунду. А mod_deflate, при некоторой удаче, перекроет этот порог в полтора раза.

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

> Мавр сделал свое дело, мавр может уходить

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

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

Ну, дык, ясный перец, что лучше всего поставить оперативки объёмом большим, чем объём данных на винте - тогда всё по разу считается и винт может "спать" до следующей перезагрузки:) Убедили - так и сделаю:)

Правильное решение :-)

А если серьезно - то на раздаче статического контента сквид действительно быстрее и легче. Хотя-бы за счет того, что он учитывает всякие Last-Modified, If-Modified-Since и прочие прелести HTTP и не шарится по дереву каталогов при попытке открыть файл.

> Ооооооо, ну куда уж нам отсталым до "продвинутых" геймеров с их "чисто десктопными" приложениями. Для кваки сжатие, явно, самое то будет. В мане так и напишем: "Всем геймерам обязательно выставить флаг сжатия на папке Games и убиться об стену". Идите ка лучше и почитайте Таненбаума?

Анонимус, ты нетрезв? Ты сам-то понял тот бред, который накропал?

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

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

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

Я могу понять - у меня на нескольких машинах процессор бОльшую часть времени загружен на 100% (обычно кодирование медиаконтента (с минимальным приоритетом))

А вот ваша упёртость - мне не понятна. Категоричность и "зарекание" от чего либо - это "по-молодости" или как?

> А вот ваша упёртость - мне не понятна.

Да какая упертость? Компилятор есть, исходники доступны, никто не мешает. Кроме математики, алгоритмов и требований, которые необходимо удовлетворить. Я просто пытаюсь донести мысль, что игра не стоит свеч - ну и как следствие чтобы непонятливые не отвлекали разработчиков всякими реквестами на "риальна палезные феньки", от которых на самом деле проку как от козла молока :-)

>Только они способны предложить алгоритм записи, не поддерживающий произвольный доступ, для файловой системы :-)

Из фидо

Файлы NTFS имеют один довольно полезный атрибут - "сжатый". Дело в том, что NTFS имеет встроенную поддержку сжатия дисков - то, для чего раньше приходилось использовать Stacker или DoubleSpace. Любой файл или каталог в индивидуальном порядке может хранится на диске в сжатом виде - этот процесс совершенно прозрачен для приложений. Сжатие файлов имеет очень высокую скорость_ и только одно большое отрицательное свойство - огромная виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и использует так называемые "виртуальные кластеры" - опять же предельно гибкое решение, позволяющее добиться интересных эффектов - например, половина файла может быть сжата, а половина - нет. Это достигается благодаря тому, что хранение информации о компрессированности определенных фрагментов очень похоже на обычную фрагментацию файлов: например, типичная запись физической раскладки для реального, несжатого, файла: кластеры файла с 1 по 43-й хранятся в кластерах диска начиная с 400-го кластеры файла с 44 по 52-й хранятся в кластерах диска начиная с 8530-го ...

Физическая раскладка типичного сжатого файла:

кластеры файла с 1 по 9-й хранятся в кластерах диска начиная с 400-го

кластеры файла с 10 по 16-й нигде не хранятся

кластеры файла с 17 по 18-й хранятся в кластерах диска начиная с 409-го

кластеры файла с 19 по 36-й нигде не хранятся

....

Видно, что сжатый файл имеет "виртуальные" кластеры, реальной информации в которых нет. Как только система видит такие виртуальные кластеры, она тут же понимает, что данные предыдущего блока, кратного 16-ти, должны быть разжаты, а получившиеся данные как раз заполнят виртуальные кластеры - вот, по сути, и весь алгоритм.

Угадай зачем нужны виртуальные кластера и как они связаны с произвольным доступом. Многие задачи можно решить подумав. Так что не надо скорострельных выводов. Если вы не знаете как решить задачу, то это не значит, что она не имеет решения.

> Угадай зачем нужны виртуальные кластера и как они связаны с произвольным доступом. Многие задачи можно решить подумав. Так что не надо скорострельных выводов. Если вы не знаете как решить задачу, то это не значит, что она не имеет решения.

Ясно, что при желании реализовать можно что угодно. Вопрос в другом: есть ли смысл.

Замути голосование на том же ixbt: пользуетесь ли вы фичей "компрессия" на ntfs: 1) да, 2) нет, 3) ой, а хто ита?

Потом обсудим результаты.

> Угадай зачем нужны виртуальные кластера и как они связаны с произвольным доступом

Какой вы умный...

Ну и что произойдет при попытке чтения 16-го и 17-го "кластеров"?

В обычной ФС ты прочтешь два блок. В "сжатой" ФС в твоем примере ты прочтешь блоки с 400..408-й, разожмешь их, возьмешь один последний блок из результата разжатия, прочтешь еще два - 409-й и 410-й, ибо ты не можешь ограничиться только 409-м - это плата за сжатие и использование словаря, и из результата разжатия возьмешь один блок. Итого - на несжатой медленной плохой классической ФС мы прочли ДВА блока, а на продвинутой ФС со сжатием прочли ОДИННАДЦАТЬ блоков.

При попытке изменить 14-й блок на обычной ФС мы берем и переписываем только его. На такой прогрессивной NTFS с суперфичей мегасжатия мы должны сначала прочесть девять блоков, разжать их в буфер, переписать 14-й блок, пожать это все снова (пусть даже оно снова ужмется до 8 блоков вместо исходных девяти) и записать снова восемь блоков на диск. Итого вместо записи ОДНОГО блока было прочитано 9 и записано 8 - итого СЕМНАДЦАТЬ, не считая времени на сжатие и разжатие.

На записи тоже не фонтан - записало приложение четырнадцать блоков, через 0.2 секуннды еще четырнадцать, и через 0.2 еще четыре. В случае обычной ФС получили 14 блоков, тут же бросили их в очередь I/O, вренули процессор приложению и оно продолжает работать. Через 0.2 секунды данные уже записаны (без использования процессора - DMA, мать его!). Пришло еще четырнадцать блоков - в очередь их, и освобождаемо процессор. Снова мгновенно. Пришло еще четыре блока - в очередь их, и освобождаем процессор.

А в случае NTFS? Ловим 14 блоков, ставим в буфер - но на диск не пишем! Ловим еще 14 блоков, 2 добиваем в буфер, еще 12 кладем в новый, старый буфер жмем (пусть до 9 блоков) и только потом ставим в очередь на запись. Получаем еще четырнадцать блоков - доиваем их в буфер, сжимаем и только потом ставим в очередь на запись - итого две задержки в ядре на трех операциях...

Вот такая вот плата за "сжатие" на NTFS, не считая необходимости дополнительных буферов. А если мы еще попросим использовать флажок O_SYNC при открытии файла, и будем писать данные порциями по 2 блока, то... То все. И давайте не будем начинать старых песен "а мы можем отключать сжатие для файлов, открытых с O_SYNC" - это уже будет называться "отмазки".

> В обычной ФС ты прочтешь два блок

перед попыткой что-то прочитать любой ФС вызывается readahed- код (Эндрю Мортон написал) и подчитывается целая охапка страниц, ибо это есть полезно

>В обычной ФС ты прочтешь два блок. И в каком году чтение/запись двух блоков была быстрее 8/16? У меня винт говорит R/W multiple sector transfer: Max = 16 Current = 16

> перед попыткой что-то прочитать любой ФС вызывается readahed- код

Ага, и разжиматься должна будет куча страниц :-)

> И в каком году чтение/запись двух блоков была быстрее 8/16?

Блоков ФС - то бишь "кластеров", которые могут быть и 4КБ, или блоков винта, по 512 байт? :-)

> Ага, и разжиматься должна будет куча страниц :-)

Ну что значит куча? Скажем, readahead заказал прочитать 20 страниц. Обычная фс эти 20 страниц и прочитает. Если же у вас 64К-кластеры, то с диска поднимутся 2 сжатых кластера, и соответственно будет прочитано 32 страницы. Т.е получается всего-лишь некоторая корректировка упомянутого ридэхеда, которая не может пагубно на чем-то сказаться. Что касается разжатия, то тот же lzo1 не сильно уступает по скорости memcpy

-edward

> если же у вас 64К-кластеры, то с диска поднимутся 2 сжатых кластера, и соответственно будет прочитано 32 страницы

Вы слегка не поняли - после прочтения, перед помещением страниц в кэш, должно быть произведено их разжатие. Multiblock count - это то количество блоков, которое HDD способен странсферить за раз - но никто не заставляет это делать. А на сжатом файле у нас выбора нет - мы обязаны прочесть весь пожатый слот - для постоянно приводимой в пример NTFS это 16 блоков ФС, даже если хотим извлечь из него один блок, иначе просто разжать ничего не сумеем.

> то тот же lzo1 не сильно уступает по скорости memcpy

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

>Вы слегка не поняли - после прочтения, перед помещением >страниц в кэш, должно быть произведено их разжатие

Обычно под прочтением страницы понимается придание ей статуса Uptodate, т.е. это включает в себя декомпрессию и все остальное.

>А на сжатом файле у нас выбора нет - мы обязаны прочесть >весь пожатый слот

Совершенно правильно, и я не вижу в этом вопиющего недостатка: это хорошо вписывается в концепцию readahed: вместо одной страницы прочитать 16, (читайте, тех, которые замаплены на этот слот). Большинство приложений читает файлы относительно большими кусками, а не выискивает там отдельные байтики по конкретным смещениям. Так ведь? :)

-edward

прикольный ролик (~3.5Mb) не совсем про файловые системы, но имеющее прямое отношение к ним: на носу перпендикулярная запись и объёмы дисков вырастут почти на порядок. Способность без проблем работать с многократно возросшей ёмкостью дисков будет немалым фактором при выборе ФС

http://www.hitachigst.com/hdd/research/recording_head/pr/PerpendicularAnimati...

> На какой загрузке процессора?

Минимальной. Почитай про lzo.

> Для всеми любимых P4 время выполнения двух задач параллельно больше времени выполнения этих же задач последовательно.

хе, так ёлы, при параллельном выполнении процессы конкурируют как минимум за кеш. Это должно быть так для любого процессора.

РейзерФС суперскоросная, я тоже тесты проводил. Но ТОЛЬКО когда монтируется с notail. Желательно и noatime. Нада выбирать, или скорость, или сжатие. А в статье про опции монтирования ничего не сказано.

P.S. JFS не проверял.

> > На какой загрузке процессора?

> Минимальной.

Ну так реализуйте свою суперфичу - вам кто-то запрещает? И если это все так "полезно" "рулёзно" и вааще все отдыхают - почему же никто этого реализовывать не стал?

> Большинство приложений читает файлы относительно большими кусками, а не выискивает там отдельные байтики по конкретным смещениям. Так ведь?

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

>От таких компьютеров избавляться надо, как от чумы. Без шуток. У меня точно такая же ситуация была под Линуксом - так что windows тут не причём. Я до сих пор не знаю, что барахлило на том компьютере, но при копировании внутри одного жёсткого диска большого файла иногда портился один бит - это мог быть глюк CPU/RAM/MB/HDD - всё, что угодно. Testmem никаких странностей не нашёл, компьютер не был разогнан.

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

Оказалось, винт битый. В середине винта оказалась область частично запоротая, около гига. Сделал два раздела, перед этой областью и позади нее. Все теперь работает стабильно (HDD Samsung какой-то).