29 февраля 2012 г. 14:04 пользователь Alex Samorukov <[email protected]>написал:
> 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 бит, > так что вроде все идеально. А версия фри/пула/фс там какая? Получал подобное с 1г памяти при svn up немалой директории, но на 8.х Если можете доступ дать - может лучше написать в freebsd-fs@ ? > > ок, я добавлю это (скруб) в список на потестиировать. >> > Снепшоты еще могут дать такое. Они тоже жрут память. Ну и конечно никакого > дедупа. > > -- Regards, Alexander Yerenkow
