On 02/29/2012 12:46 PM, Slawa Olhovchenkov wrote:
http://dmih.livejournal.com/671810.html
===
XFS на томе, остановленном аварийно, утомляет скоростью монтирования;
Ну да, том большой (8 Тб), там очень много файлов, но простоте меня,
RESET я жал почти из простоя. И вот при монтировании она уже считала с
диска около 3 Гб (!), случайным чтением конечно.
Это лог транзакций-то прогнать..
Час - легко. Не проверка, просто монтирование. Причем не
перестраховщики, нельзя сказать, что она чем-то очень полезным
занимается - может собственно говоря и не примонтировать, пошлет
легко, а проверка этого тома вообще длиться неделю будет. Не квартал
конечно как ext3, но всё равно.
Я уж не говорю о том, что спокойно отправляет в фатальный OOM сервер с
4 гб памяти, если использовать его как машину для резервных копий с
томами такого размера - утечки памяти там какие-то, slab-ы растекаются
неосвобождаемые и так далее.
Еще в xfs бесит то, что журнал иногда признается негодным и тогда всё;
но это болезнь всего unix-way-я, оптимистичных алгоритмов там не
делают в принципе, там если на терабайтном томе один бит не так стоит,
то сиди неделю чекай, не думаю что какая-то система будет вести себя
иначе..
===
весело, чо.
1) Про 4 гига памяти и ООМ - сомневаюсь. По крайней мере у меня не
проявлялось, хотя допускаю, что все возможно. Я ее использую на 4 гигах
на машинке с огромными maildirs. Справедливости ради замечу что ext3 на
операциях с данными ящиками (там имап используется как внутренний
протокол обмена, преимущественно) просто помирал навсегда, у него очень
плохо с гигантским количеством файлов в директории. У зфс есть другой
пренеприятнейший глюк - если создать миллион файлов в папке, а потом их
удалить - папка все равно работает медленно.
2) Про время проверки в worst case - да, оно большое, иногда _очень_
большое. 1 раз мне потребовалось своп примонтировать для проверки тома.
К счастью - это редкий случай. Но опять же - у UFS оно как минимум не
меньше, а вероятность наступления - много больше. С ZFS этого недостатка
нет, так что тут явное преимущество (как и у бтрфс, когда его, наконец,
допилят)
3) Про негодный том - ну тут у зфс никаких преимуществ, получить
немонтируемый том в зфс мне удавалось, особенно на ранних версиях фри. И
дальше все, либо бекапы, либо мучительное изучение структуры фс и
переписка с разработчиками.
4) В последних ядрах (конкретнее - 3.1) было проведено огромное
количество улучшений в XFS, как с точки зрения производительности, так и
с точки зрения надежности, т.е. проект вполне себе живой. У ZFS
ситуация, увы, несколько непонятная. Я очень надеюсь, что у community
хватит ресурсов для развития _вне_ оракла, а оракл (пусть и с
опозданием) всеже будет выкладывать исходный код. Но вот как-то зная
склонность Ларри превращать в говно все, к чему прикасается его
менеджмент - я не очень оптимистично смотрю на будущее.
Кстати, на одной из систем с зфс у меня есть смешной глюк - grep -R
shit /usr/include гарантированно приводит к панике. Это моя testing/dev
машина, никак не соберусь репорт сделать, готов к ней дать доступ без
проблем, хоть по в4 хоть по в6, если у кого есть желание поотлаживать и
понять в чем проблема. Скруб не лечит, если чо. Памяти - 16 гигов,
архитектура 64 бит, так что вроде все идеально.
ок, я добавлю это (скруб) в список на потестиировать.
Снепшоты еще могут дать такое. Они тоже жрут память. Ну и конечно
никакого дедупа.
