Треш с ext4

Так что 256*256 каталогов создаются почти сразу.

Я про другое. Когда каталог создаётся, под него выделяется один блок. Когда места становится мало, выделяется ещё немного места, и так далее. Проблема в том, что когда нужно выделить дополнительное место, рядом с первым блоком уже свободного места нет, поэтому большие директории почти всегда фрагментированы:

$ ls -ld 2
drwxr-xr-x 2 rinat rinat 73728 Фев 10 15:39 2
$ /usr/sbin/filefrag 2 -v
Filesystem type is: ef53
File size of 2 is 73728 (18 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0 19931412               1 
   1       1 19931409 19931413      2 
   2       3 19931513 19931411      1 
   3       4 19931552 19931514      1 
   4       5 19931608 19931553      1 
   5       6 19931612 19931609      3 
   6       9 19931783 19931615      1 
   7      10 19931776 19931784      4 
   8      14 19932368 19931780      3 
   9      17 19931221 19932371      1 eof
2: 10 extents found

Вот и приходится при поиске в директории сначала собрать её по мелким кусочкам. И самое главное: даже если удалить все файлы, директория меньше не становится. Она так навсегда и останется фрагментирована, e4defrag директории никогда не трогает.

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

Тогда почему в ext4 добавили упаковку хвостов? По сути это то же самое, что в reiserfs по умолчанию (tails=small), только размер ограничен 100-150 байтами вместо 4k.

не замечаешь что демагогию разводишь? старческие болячки?

а ты в то время под стол ездил?

Это btrfs и zfs.

Ага, ибо c-o-w и в них фрагментация вложена изначально, by design.
Но с приходом ссд на это более, чем пофигу.

терабайтные ssd скоро будут?

терабайтные ssd скоро будут?

Нафиг они нужны? Ты хранишь все порно у себя локально?

Хранить терабайты мелких файлов в over9000 вложенных директорий.

Хранить терабайты мелких файлов в over9000 вложенных директорий.

http://market.yandex.ru/model.xml?modelid=7345155&hid=91033

Только две файловые системы не деградируют. Это btrfs

Ага. btrfs не деградирует, потому что умирает сразу :D У меня на тестах она под нагрузкой начинала тупо сыпаться.

У меня с ней всё ok под нагрузками на экспериментальном map/reduce кластерочке.

Я про другое. Когда каталог создаётся, под него выделяется один блок. Когда места становится мало, выделяется ещё немного места, и так далее.

Как я присал, кеш заполняется до стабильного уровня за несколько дней. Вот тут пример фиолетовой линии /var/cache/sites:
http://www.balancer.ru/img/forums/1302/munin-df-month-02.png

Потом находится в динамическом равновесии, старые файлы грохаются, новые создаются.

Так что «прошлый раз» он заполнился в начале 2010-го, когда я делал этот сервер. И до 2012-го всё вполне шустро было. Лишь в прошлом году тормоза начались. Подозреваю, что виной тому какие-то процессы в разработке ядра. Не первый раз же уже такое. Помню, какой фурор произвело появление в ядре CFQ. Как всё с этим шедулоером летало. Но прошло пару лет и от включения CFQ нет и малейшего следа старого эффекта :)

Нафиг они нужны? Ты хранишь все порно у себя локально?

Мы только что о серверной нагрузке говорили. Почему ты считаешь, что ФС только для порно нужны?

У меня с ней всё ok под нагрузками на экспериментальном map/reduce кластерочке.

Раз на раз не приходится. Вон, с XFS у меня тоже долго всё хорошо было, а дома — и сейчас хорошо. А на сервер один раз в порядке эксперимента воткнул и получил Подскажите какую ФС использовать под нагруженный mysql сервер (комментарий) :)

XFS под нагрузками ложится. Подтверждаю. Тестировалось на искоробчных ядрах на убунте 10.04 и 12.04.

Мистика какая-то. Вроде все изменения делают, чтоб быстрее было, а выходит наоборот.

Мистика какая-то. Вроде все изменения делают, чтоб быстрее было, а выходит наоборот.

По-моему, не мистика, а общий тренд. Те же браузеры взять. [почти] каждая новая версия заявляется более быстрой и оптимальной, чем старая — а в итоге запустишь какой-нибудь Firefox 1.0 или Opera 5.0 и охреневаешь от реактивности. С видеорайверами также было, пока за ними народ ещё следил. Вроде, оптимизации и ускорения в новых версиях, а совсем древние куда быстрее были :) Вот и с ядром, походу, такая же фигня.

Вон, по CFQ отзывы остальсь в истории:
http://www.balancer.ru/tech/forum/2006/09/t50753--cfq-io-schedule-i-proc-sys-...

У меня комп никогда так шустро и плавно не работал, как первые пол-года (или около того) после перехода на CFQ :)

Можно ещё переход от Beryl к Compiz вспомнить, но тут другая история. После этого перехода тормозить сразу стало сильно, но долго надеялись, что, таки, разработчики Beryl после вливания в Compiz смогут оптимизировать последний. Увы, увы...

Нет, кривые руки.

Проблемы с ext4 были только в Jaunty.

Так точно. Это же оффициальная файловай система Linux.

Потому что срок поддержки RHEL - 10 лет.

ext4 как и все прочие разработал Теодор Цо. Он в команде Дебиана?

Теодор Цо. Он в команде Дебиана?

Он поддерживает e2fsprogs в debian, да. Не знаю, считается ли это «быть в команде».

Кстати, как там твой дефрагментатор reiserfs поживает?

Видимо да.

Кстати, как там твой дефрагментатор reiserfs поживает?

Работает, реализовал всё, что изначально планировал.

Вон, по CFQ отзывы остальсь в истории:

Там первый комментарий — про возможность отправки сообщений во время компиляции. То есть все остальные планировщики были настолько плохими, что IM не мог послать сообщение? Я тут подумал, а может быть нет прироста не потому что CFQ стал хуже, а потому что остальные стали лучше?

Дефрагментацию уже можно прерывать?

Я тут подумал, а может быть нет прироста не потому что CFQ стал хуже, а потому что остальные стали лучше?

ИМХО, там ситуация сложнее. Думаю, что затыки были от кривых драйверов на кривом железе. CFQ позволял на таком хорошо и комфортно жить. Сейчас кривого железа стало меньше, драйвера стали лучше, так что альтернативные шедулеры уже так сильно не глючат. Но и CFQ стал реально хуже. Под высоким дисковым IO сегодня системы начинают тупить и тормозить намного больше, чем на куда более старом и тормозном железе лет 7 назад.

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

Сейчас такого нет. Даже на SSD при очень активной работе в GUI появляется задумчивость. А обычный винт под нагрузкой может начать [снова, как и лет 15 назад :D] затыкать звук, и открытия меню можно секунды ждать...

Дефрагментацию уже можно прерывать?

Да, Ctrl-C обрабатываются: после нажатия он доделает текущий кусочек работы и завершит выполнение. Все операции с метаданными журналируются в том же журнале и в том же формате, что и в драйвере, так что при аварийном завершении всё починится драйвером при монтировании (ну или fsck проиграет журнал, что в целом то же самое). Пару раз я пробовал для проверки процесс убивать во время работы — с ФС всё ок.

В той теме я шапку уже обновил (раньше звёзд не хватало).

Поделись такими командами, плз.

Что ну-ну? Не я fsck делал, а чувак который имел физический доступ к серваку :)

Угадаю ОС по описанию бага. И да, ext4 тут ни при чем.

По твоей логике виновата ОС :) Интересно, каким-таким образом?

Понятия не имею. Криво собранное ядро, какой-то портящий ФС софт, кривой драйвер ФС. Вариантов может быть очено много.

Что именно ясно? Убунта говно по определению, а для сервера - тем более. Уж лучше Debian unstable поставить.

Всё было по дефолту. Из специфического софта была только Jira с говноявой.

При чём здесь мемтест? Ось ставилась без ошибок, граб на екст4 не заводился.

но мои руки тут ни разу не при чём.

«вся система стояла на /»

От того что кто-то поставил всё на / мои руки кривее не стали. Да и к теме это никакого отношения не имеет совершенно.

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

Попсовость - не показатель качества. Что на ext3 такое случилось - что ж, бывает. А вот с ext4 у емня постоянно какие-то грабли. Поэтому - нафиг. Тем более альтернатив море.

А, ну в убунте всякое возможно, да :)

Что именно ясно? Убунта говно по определению, а для сервера - тем более. Уж лучше Debian unstable поставить.

Ясно, что ты админ локалхоста, вот что ясно.

Вывод ни о чём.

что там в райзере с fsck? Оно нормально теперь работает, или как раньше «работало»? Можно попробовать убитый диск под нагрузкой поресетить?

Поделись такими командами, плз.

да любыми. dd хотя-бы. Или просто cat >/dev/sdXY.

ломать не строить.

Вывод ни о чём.

Википедии это скажи, ага. У которой все сервера на убунте. А потом рассказывай бабушкам у подъезда про её нестабильность.

Поделись такими командами, плз.

Лолд. Чтд прямо наяву.

Что ну-ну? Не я fsck делал, а чувак который имел физический доступ к серваку

этот чувак лог должен был сделать. man script, screen ему в помощь. Хотя-бы для себя. А так - хрен его знает, что там было.

От того что кто-то поставил всё на / мои руки кривее не стали.

Но понимание кривизны ситуации, как видно, отсутствует.

Да и к теме это никакого отношения не имеет совершенно.

Вообще-то имеет, в некотором смысле.

При чём здесь мемтест? Ось ставилась без ошибок, граб на екст4 не заводился.

при кривой памяти ФС сыпется. Это факт. Очевидно, что многое хранится в памяти, в кеше, и сбрасывается на диск ессно без каких-то проверок. А сбрасывается НЁХ. В итоге ФС приходит в битое состояние. Это может привести к сбоям, зависаниям, ошибкам и вообще к чему угодно, ибо диск все тесты проходит. Часто и ОС грузится без проблем, и даже работает немного - бой может быть в конце.

От того что кто-то поставил всё на / мои руки кривее не стали. Да и к теме это никакого отношения не имеет совершенно.

ну на один раздел - не лучший вариант. ИМХО.