2anonymous (*) (2003-08-24 03:13:07.982124)

бля═ну═ты═дятел

представь═себе═Что═одна═FS дает═дикуЮ фрагментациЮ а═вторая═нет. но═при═твоем═тесте═это═поЧти═не═отразится

Нюню - все FS тестировались в абсолютно одинаковых условиях - файл 1 - какая нафиг фрагментация ?

Гы, а какая из ФС может бороться с фрагментацией внутренними средствами ? 8)))

А это спецом для тех кто думает, что он что-то соображает по существу вопроса 8)
бэнчмарк на "реальном" диске - bonnie++ 1.03a
создавлось 40К фалов в 1000 директориях размером от 10 байт до 100к
(машина и ядро те же что и в случае с RAM disc - партишен один и тот же)

time=11m43.031s
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Reiser         600M 21845  94 198759  76 37040  10 30885  99 890000  99 +++++ +++
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
  40:100000:10/1000   744  17   178   2 19342 100   691  17    79   1  1118   9
Reiser,600M,21845,94,198759,76,37040,10,30885,99,890000,99,+++++,+++,40:100000:1
0/1000,744,17,178,2,19342,100,691,17,79,1,1118,9
--------------------------------------------------------------------------------
------------------------------------------------
time=13m0.177s
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Ext2FS         600M 28677  97 263168  46 37027   7 30835  99 856325  98 +++++ +++
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
  40:100000:10/1000   587   6   317   4  3775   5   535   6    84   1  2331   4
Ext2FS,600M,28677,97,263168,46,37027,7,30835,99,856325,98,+++++,+++,40:100000:10
/1000,587,6,317,4,3775,5,535,6,84,1,2331,4
--------------------------------------------------------------------------------
------------------------------------------------
time=14m22.932s
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
XFS            600M 23582  98 200236  38 31941   8 30764  99 833755  99 +++++ +++
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
  40:100000:10/1000   463   8   381   5  2964  17   386   6    82   1   116   1
XFS,600M,23582,98,200236,38,31941,8,30764,99,833755,99,+++++,+++,40:100000:10/10
00,463,8,381,5,2964,17,386,6,82,1,116,1
--------------------------------------------------------------------------------
------------------------------------------------
time=16m18.401s
Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
JFS            600M 15625  56 47571  10 60032  11 30559  98 863353 101 +++++ +++
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
  40:100000:10/1000   305   4   350   5  3360   5   302   4    77   1   141   0
JFS,600M,15625,56,47571,10,60032,11,30559,98,863353,101,+++++,+++,40:100000:10/1
000,305,4,350,5,3360,5,302,4,77,1,141,0
--------------------------------------------------------------------------------
------------------------------------------------

Неправда-ли наблюдается довольно любопытная корреляция с результатами dd на RAM disc ? :)
Учите матчасть, вьюноши, и не спорьте с дядями 8) (А тем более - со старыми пердунами - вроде меня)

(Кстати JFS на rewrite SO оказался быстрее всех - но в остальном кругом слил)

Гм - надо отдать должное - JFS меньше всех грузит проц, а Reiser жрет как не в себя.

ой бля, bonnie он решил напугать и матчастью ;) ну да, reiser ненамного делает xfs на мелких файлах, и че? ты одни сорсики на винте держишь? рам диск ты наш ;) иди поперди лучще, имхо у тя что ни brain fart то в лужу ;).

Это что, все что ты можешь из себя выдавить ? конструтивно ... 8)

2anonymous (*) (2003-08-24 07:59:38.041018)

А ведь XFS слил и на одном большом файле - так что не гони !

идите нахуй, господа. как юзал хфс так и буду юзать. А вы в сад.

Насчет "тестов" на RAM-диске действительно детский сад. Идиотом надо быть, чтобы не понимать что реальное быстродействие файловой системы зависит именно от количества дисковых операций, которые необходимо выполнить. Наверное он воображает, что все фс магическим образом определяют номер блока по имени файла.

А вы наверное думаете что на РАМ диске FS работает по другому ? :)) Можно считать что это очень быстрый диск - а механика работы кругом одинакова.

Однако я чуствую, что разговоры эти бесполезны: трудно убедить эскимоса, что в Африке нет зимы. Засим - юзайте, кто во что горазд - никого здесь не насилуют :)

2anonymous (*) (2003-08-24 07:59:38.041018)

Да забей ты на этих уродов - они не отличают быстродействие FS от скорости винта - для них это одно и то же.

Нет, а я вот не могу разобраться, винт-то один и тот же? файлы одни и теже, почему тогда рейзер копирует и тп быстрее всех? Что еще можно делать на винте что бы почувствовать крутость иксфс или любой другой фс именно в скорости работы? А то если результаты тестов не нравятся все начинают кричать что это неправильно, привели бы свои тесты для сравнения тогда. Просто действительно хочется разобраться.

>они не отличают быстродействие FS от скорости винта - для них это одно и то же.

Ты хочешь сказать что если на винте стоит reiserfs то он начинает работать быстрее??? Впрочем меня это вполне устраивает :)

Да, блин, LOR во всей своей красе - человек проделал конкретную и привел конкретную цифирь. Вместо того чтобы задуматься над всем этим - вылезает очередной Вася Пупкин из Мухосранска и орет благим матом в незензурных выражениях всякую ахинею.

>привели бы свои тесты для сравнения тогда

Дык их ведь делать надо - гораздо проще погундосить насчет своей любмий ФС - и обложить матами всех кто эту ФС осмеливается критиковать ;)

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

Почему разные файловые системы выполняют операции с разной скоростью? Если рассказывать сильно упрощенно, то в основном вопрос сводится к тому, сколько дисковых операций нужно выполнить и какое расстояние головкам для этого придется преодолеть. Например в старой доброй fat при записи файла из одного блока нужно было как минимум 5-6 раз обратиться к диску (прочитать fat, прочитать директорию, найти свободное место в fat, модифицировать и записать fat, модифицировать и записать директорию, записать сам блок и т.д.). Причем количество операций могло быть много больше. Если, например, директория занимала несколько блоков, то для создания нового файла в этой директории необходимо было прочитать их все (чтобы убедиться, что файл с таким именем не существует). При этом директория могла быть в середине диска, сам файл в конце, а fat всегда в начале. что еще больше увеличивало время выполнения операций за счет времени на позиционирование головок. В xfs почти все внутренние структуры реализованы в виде двоичных деревьев. Что с одной стороны увеличивает время на их создание (добавить запись в базу данных всегда занимает больше времени, чем добивать строку в конец файла), но, с другой стороны, минимизирует время на поиск по этим структурам. В частности поэтому время выполнения операций на RAM-диске это не показатель. Все алгоритмы, которые убыстряют работу файловой системы за счет, например, оптимизации перемещения головок при дисковых операциях на Ram-диске будут только замедлять работу и увеличивать использование cpu. И так далее. Если кому-нибудь будет интересно, постараюсь кинуть url по таким вопросам.

> Все алгоритмы, которые убыстряют работу файловой системы за счет, например, оптимизации перемещения головок при дисковых операциях на Ram-диске будут только замедлять работу ...

Покажите мне место в XFS где она определяет геометрию носителя! :)

Скажу больше - реальная геометрия винта зачастую вообще недоступна - а ориентироваться на 63/255/nnnnnn - несколько маразматично :)

А как быть с файловыми системами создаными в файле ? Какая уж там геометрия ! :) И че она там будет оптимизить ? :)

> Покажите мне место в XFS где она определяет геометрию носителя! :)

Как Вы думаете, почему вместо того чтобы хранить всю информацию о распределении дискового пространства в одном месте в начале диска как это было в fat все нормальные файловые системы (даже доисторическая hpfs) разбивают диск на "полосы" и записывают копии суперблока (или его функционального эквивалента) с определенным шагом по всему диску?

Хехехе - делается это совсем по другим причинам (а именно живучесть системы ) хотя в XFS (и не только в ней) например можно исказить естественную нумерацию логических блоков - это важно при записи на рэйд массивы - типа первые 64к пишутся на первый диск вторые на второй и так далее (увеличивается скорость за счет параллельной работы нескольких винтов) - но к головкам это отношения никакого не имеет.

Если посмотреть соответствующие сырцы - то можно убедиться в том, что все файловые системы оперируют только одним понятием - смещением блока от начала FS. Геометрией винта там нигде и не пахнет.

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

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

Если бы у старого пердуна хватило бы мозгов на посмотреть собственные результаты, то он бы увидел, что у XFS скорость чтения быстрее чем у всех приведённых FS.

Если бы у старого пердуна хватило бы мозгов на посмотреть собственные
результаты, то он бы увидел, что у XFS скорость чтения быстрее чем у
всех приведённых FS.

И ещё XFS весьма желательно монтировать с noatime.
Меня приколол тест. REISERFS очень быстро стирает
файлы при CPU load 100%. :)) LOL. У вас что FS для того
чтобы rm -rf делать?

Зы причем это искажение нумерации нужно только для дешевых контроллеров, которые не умеют делать нормальный raid-N. J-BOD класс.

РЕАЛЬНОЕ ПРЕИМУЩЕСТВО

Попробуйте поставить Mldonkey ...

Записать паралельно песколько Фильмов ....

И потом проверить на скорость их чтения с винта . По ОДНОМУ !

При ЕХС2ФС было не больше 1 МЕГА А при ХФС не меньше 7 МЕГ .

У меня стбильно машина висне из за винта но после перезагрузки подгимается всегда на ура и только при ЛОГ РЕКАВЕРИ .

При ЕХС2ФС 10 мин на проверку .

ЗЫ Тестирование с РАМ диском в САД однозначно !!!

PS

ЗЫ тестит ХФС нужно тольно на ядрах 2.5.Х и более новых Так как там проблемы с кешированием метаинформации от ХФС.

MfG

Konstantin

> Хехехе - делается это совсем по другим причинам (а именно живучесть системы )

Нет, это делается не для этого. Или, если хотите, не только для этого. (C целью повышения надежности было бы достаточно просто хранить несколько копий информации не разбрасывая ее равномерно по всему диску. Как 2-е копии fat) Только прошу не придираться к терминологии. Таблицы индексных дескрипторов хранятся на диске как легко догадаться в единственном экземпляре (в отличие от собственно информации суперблока, которая естественно дублируется). И разрушение любой таблицы приводит к очень неприятным последствиям (поскольку это, по крайней мере в ext списки). Но когда драйвер читает эту таблицу с целью найти, к примеру, нужный индекс или просматривает список свободных блоков, он всегда найдет блок с номером не очень сильно отличающимся от номера того блока, в котором эта информация хранится. И ему не придется тащить головку на другой конец диска. Независимо от его физической геометрии (это, как правило, верно и для файловых систем созданных в файле).

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

>>>Если бы у старого пердуна хватило бы мозгов на посмотреть собственные ....

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

Вы, наверное, преисполняетесь осознанием собственной значимости, пытаясь крайне неумело оскорбить меня? Бывает :) Покричите еще - может полегчает. Уйдете с гордо приподнятым задом и будете пальцы загибать, рассказывая бабушкам во дворе какой Вы умный - и как лихо со всем разрулили :)

Продолжайте, pls :)

У меня собственно, получилось примерно похожее распределение по скорости с той только разницей, что ext2 у меня не было, а была ext3. Быстодействие распределилось так: reiserfs > xfs > ext3 > jfs. Никакие ключи для увеличения быстродействия не использовались. Однако и при этих условиях на определенном наборе файлов xfs оказалась на первом месте; Короче для себя я сделал вывод, что файловую систему надо выбирать под конкретные задачи. Универсального рецепта здесь нет.

>C целью повышения надежности было бы достаточно ...

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

Вернемся к нашим баранам.

То бишь к RAM disc'у - итак у нас осталась одна проблема - отключить кеширование на нем - чтобы получить чистый и незапятнаный ничем результат быстродейсвия ФС. (А не винчестера+ФС) Мне интересен именно этот аспект - не знаю кому как :)

Какие будут идеи ? 8))))

С идеями - туго! Нам бы поорать ...

> Какие будут идеи ? 8))))

а если его в sync замаунтить?

пробовал - кешит все равно -osync немедленно сбрасывает инфу на диск - но из кеша ее не удаляет

а с /proc/sys/vm/bdflush поиграться?

хз - не пробовал

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

> предполагается, что для доступа к соседнему сектору не придется тащить головку через весь диск

Кем предполагается? Что значит "к соседнему"? Следующему по номеру? Я думал, что для б/м новых дисков номер сектора не может сказать _ничего_ о его физическом расположении и о необходимом перемещении головок.

> И ещё XFS весьма желательно монтировать с noatime.

А Reiser нежелательно?

P.S. И еще nodiratime :)

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

Пример - если некая ФС пишет файл в несколько потоков 4 КБ в один, 4 в другой, и т.д. поочередно, потоки равномерно раскиданы по разным частям раздела, а другая ФС пишет файл "линейно" в один поток блок за блоком. При чтении в режиме произвольного доступа одновременно по нескольким файлам у первой ФС скорость может оказаться и больше, чем у второй.

Поэтому испытания _нужно_ производить на железе, а не на RAM-диске, ибо на RAM-диске вы разницы не ощутите.

> Пример - если некая ФС пишет файл в несколько потоков 4 КБ в один, 4 в другой, и т.д. поочередно, потоки равномерно раскиданы по разным частям раздела, а другая ФС пишет файл "линейно" в один поток блок за блоком. При чтении в режиме произвольного доступа одновременно по нескольким файлам у первой ФС скорость может оказаться и больше, чем у второй.

А может (и скорее всего будет) и меньше.

> Поэтому испытания _нужно_ производить на железе, а не на RAM-диске, ибо на RAM-диске вы разницы не ощутите.

так говорили же ему уже. а он в ответ посоветовал hdparm -tT воспользоваться.

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

Оне (реальные устройства) бывают существенно разные. Вывод - тюнинг ФС не имеет смысла. Надо использовать NTFS, как завещал великий Irsi.

Интересно а что за проблемы с кешированием метаданных в ядрах 2.5 ?

> Кем предполагается? Что значит "к соседнему"? Следующему по номеру? Я думал, что для б/м новых дисков номер сектора не может сказать _ничего_ о его физическом расположении и о необходимом перемещении головок.

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

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

> Кем предполагается? Что значит "к соседнему"? Следующему по номеру? > Я думал, что для б/м новых дисков номер сектора не может сказать > _ничего_ о его физическом расположении и о необходимом перемещении > головок.

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

>>> а он в ответ посоветовал hdparm -tT воспользоваться.

Мужики, еще раз, я хочу замерить производительность драйвера FS.

Подскажите лучше как отключить кеширование на одном конкретном диске.