Производительность файловых систем. ext2 vs ext3 vs ext4dev vs jfs vs reiserfs vs xfs.

Ну, видишь, у тебя просто ситуация другая Привычки для другой сферы... А так - да, у меня тоже серверок один под Gentoo за файрволом стоял около полутора лет вообще без всякого обслуживания и обновлений. Чисто файлопомойка, прокси, NAT... Да ещё при этом народ его периодически вырубал, выдёргивая вилку из розетки Вот там - да. /usr можно было в r/o ставить...

Только на скорость чтения не влияет нифига. Уже пробовал

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

Balancer, у вас проблемы с нехваткой железа?
Почему бы не поиграться на рабочем компутере, а не сервере, я даже на своих виртуальных не позволил бы таких игрищь ))).
И файлы проще генерировать с dd if=/dev/zero, чем рипать диски.

Balancer> По поводу XFS - думаю тут, не воткнуть ли второй винт, отрезав раздел гигов на 30 и пощупать имитацию торрент-раздачи. Только как - не придумал ещё. В голову приходит заполнить 1.4Гб РИПами, взять потоков 10 и дёргать случайные куски из случайных мест файлов. Насколько такой тест будет адекватным? Вопрос только - как средствами shell правильно обращаться в середину файла? tail/head, полагаю, это не то получится.

А, вот ты про что. Это только мысли. Вообще - зачем мне геморроиться с нарезкой нулевых файлов некоторых диапазонов длин (которые, к тому же, того гляди, как бы не sparced бы стали), когда мне проще залить сотним мегабайт готовых файлов с NFS по гигабитке?

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

Да, и в том числе скорость записи на хдд

/dev/zero для некоторых типов fs - нечестный ход
1) такие файлики поджать можно до пары блоков
2) скорость работы с ними тоже будет не показательна

В продолжение недавней темы #2225516

Первые практические оценки. Загрузка системы, процессор и io за неделю:

Вертикальный раздел — перезагрузка (я сперва надеялся избавиться от kworker обновлением ядра). Потом перенос данных на новый раздел, потом заполнение кеша — следующие два дня. И, вот, сегодня день после «выхода на режим». В принципе, не так наглядно, как на соответствующем по времени графике времени генерации файлов самого munin:

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


Хотя, повторюсь, не знаю, насколько именно reisrefs характерна, может быть вынос на новый раздел со свежей ext4 себя также бы повёл. По тестам, «приближённым к боевым» (многопоточность, фрагментация), ext4 у меня была заметно быстрее reisrefs. Но практика может быть иной. Не исключено, что ext4 подвержена со временем деградации, как и reiser4 (та тоже поначалу очень быстрая, а через пол-года активной работы на десктопе превратилась в ад). Вот про именно reiserfs — она, вроде, не деградирует. Старый сервер на ней проработал в жёстком режиме лет шесть и проблемы затыкания системы на дисковой активности у меня не вылезали.

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

// Транслировано с juick.com