[sisyphus] Re: f**k reiserfs

[Alexey Lubimov]

nikodim пишет:

>>>Мораль такова:
>>>
>>>      
>>>
>>мораль такова - меньше читайте рекламу, а если читаете, то читайте, что 
>>написано, а не то, что вам хочется прочитать.
>>    
>>
>
>Наезд не в тему. Причем здесь реклама? Я вообще по жизни скептик :)
>
Скептик, не скептик, но заявлять, что журналируемая фс лучше переносит 
резет или сбой по питанию, чем не журналируемая может только сильно 
промытый дилетант.
А уж заявление про надежность NTFS в свете ext2 вовсе за гранью критики.

Лучше всего от проблем с питанием спасает  ext2 + опция sync. Журнал тут 
только помеха.

>>>Главное качество журналируемой системы - обеспечить логическую целостность
>>>тома (раздела) при сбоях питания, или при внезапном Reset'е, например.
>>>      
>>>
>>логическая целостность != целостность содержимого файлов
>>    
>>
>
>Да, это так. Журналируются только метаданные. Если произошел сбой в момент
>записи файла, его уже ничто не спасет (хотя, теоретически и здесь можно
>организовать логику транзакций, но с файлами произвольного содержимого
>транзакции, ИМХО, бесполезны :()
>
Надо понимать, что любая логика транзакций будет работать только в 
случае целостности журнала (или данных). В нашем случае это недостижимо.


>>>А наличие журнала наоборот снижает производительность по сравнению с тем
>>>случаем, если бы журнала не было.
>>>      
>>>
>>журнал позволяет определить сам факт необходимости вмешательства и не 
>>более того.
>>chkdisk быстрый и более корректный, по другому.
>>    
>>
>
>fsck более быстрый, естественно. Но в среднем операции очевидно медленнее
>из-за необходимости записывать что-либо в журнал транзакций.
>
Это зависит от организации. В XFS сделано все или почти все, чтобы 
журналирование не мешало быстродействию.


>>>Когда один гражданин в этой дискуссии сказал, что XFS требует обязательно
>>>UPS для обеспечения стабильного питания, т.к. "агрессивно кэширует
>>>метаданные", то я задаюсь вопросом, а нахрена тогда ей журнал? С
>>>"агрессивным кэшированием" и без журнала она была бы еще быстрее :)
>>>      
>>>
>>есть разные отказы. отказ по питанию лечится установкой ups, чего не 
>>сказать про остальные.
>>    
>>
>
>Так вот в чем дело!
>Это два разных вопроса - журналируемость и чувствительность в сбоям питания.
>Дело не в журнале, а в т.н. "ленивом кэшировании записи", когда данные,
>предназначенные для записи на диск, физически записываются не сразу, а в
>момент простоя (покоя) системы. Степень "ленивости" должна регулироваться в
>ядре или в настройках ФС. Если система не "ленивая", то сбои питания ей тоже
>опасны, но меньше, т.к. изменения в файлах немедленно (почти) записываются на
>диск. И пусть ФС как угодно агрессивно кэширует метаданные, лишь бы она без
>задержек синхронизировала изменения с диском, не откладывая запись на потом.
>Тогда и без UPS прожить можно (на рабочей станции, т.к. сервер без UPS как
>автомобиль без тормозов :).
>  
>

XFS создавалась с учетом требований SGI. Это отказоустойчивая, 
полнофункциональная промышленная ФС.
Промышленная, это значит, что график отклика ФС не имеет провалов на 
максимально широком диапозоне нагрузок. Это самая масштабируемая ФС под 
линукс.
Полнофункциональная, это значит, что XFS имеет в себе и квоты, ACL, 
минимум ограничений на размер файлов, директорий и прочего.
Отказоустойчивая, это значит, что журнал и данные ведуться раздельно 
(как вариант, на разных устройствах) и позволяют держать состояние ФС 
под полным контролем.
Отказ по питанию из за отсутствия юпса не рассматривается в XFS, как 
отказ. Для low cost систем есть другие ФС.

"Неленивое" кеширование записи неизбежно повлияет на график загрузки ФС, 
так что этот вариант вряд ли вообще рассматривался в SGI.