> восстановления при крэше), до 20+ (!!!) секунд доходит зависоны. Ну вот это - совсем непорядок. Факт!
> Любое обновление yum update превращается в ад.
Не хочу ничего сказать, но когда я пользовался шапкой, меня скорость работы yum выбешивала и на EXT3. А на виртуалках с 256 мегами памяти ему вообще оперативы не хватало для установки особо жирных пакетов. Yum мне запомнился как мерзкий и тормозной пакетный менеджер, уж извините.
> Там тонны fsync, так как нужно быть уверенным в том что данные нового пакета таки записаны.
На самом деле федористы помнится пилили специально для бтр-а намного более умный подход: до апдейта лепится снапшот (достаточно 1 раз синкануть именно его на диск) а далее ставятся апдейты. Не понравилось? И хрен с ним! Откатимся на снапшот и готово, можно попробовать еще раз. Зачем при таком подходе вообще fsync-ать все и вся - загадка природы. Может недоделали еще эту логику?
> Собственно с этой претензии обычно и начинаются разборки в btrfs-devel. Годами.
> Вот и ныне там . C kernel 3.1.
По моим наблюдениям, за пару лет btrfs прилично подтянули. Хотя честно говоря я никогда ее не бенчил на предмет кучи fsync, но как минимум sqlite там стал работать заметно резвее (он с его журналами тоже упирался в это, да и продолжает). Но вообще, а вы не погорячились использовать ее как загрузочную ФС в боевой системе то? Федористы вон отложили переход на оную как дефолтную на как минимум 1 релиз, что как бы намекает что зелен виноград. Всему свое время и место.
> Загрузка ОС дольше раза в 4. На глазок - btrfs превратила комп в венду.
В 4 раза - по сравнению с чем? С ext4? Ну так EXT4 не умеет и 1/10 того что умеет btrfs. Хотя все-равно - не понятно чему там в 4 раза тормозить. У вас времена доступа к файлам чтоли включены? Или чего оно там в 4 раза делает? А bootchart посмотреть и вообще запрофайлить что и где затыкается? Систему грузить честно говоря не пробовал (я не камикадзе, извините) а как data диск оно вроде довольно съедобно уже работает. Хотя от набора файлов и операций зависит, разумеется.
