The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Отдельный RSS теперь доступен для каждого обсуждения в форуме и каждого минипортала.
. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..." +1 +/
Сообщение от AlexAT (ok), 31-Окт-12, 07:41 
> бред не хочется даже сильно коментировать. Я понимаю что мисье не программист,
> а Одминистратор - которому напели баек и в которые он поверил.

Несдержанность - удел вьюношей. К слову, я как раз-таки системный программист, и прекрасно представляю, о чем идет речь. ARC имеет преимущество только перед ядрами младше 2.6.26, в 2.6.26 (или в 2.6.25 - точно не помню) реализовали механизм Split LRU, который, в общем-то, и есть примерно то же самое, что применяется в ARC, только без изменения самого механизма замены страниц.

У ARC три проблемы:
1. ARC плохо работает (сильно нагружает систему) с малыми объемами кэша. Это проистекает из проблемы (2).
2. Алгоритм замены в ARC таков, что под высоким давлением на кэш работает крайне неэффективно. Это порождает проблему (1). Eviction страниц может занимать очень приличное время.
3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать в приложениях можно только на страх и риск.

> Системный кэш в Linux kernel - это очень сильно порезаная LRU policy,
> ZFS требует для своей работы ARC policy (http://en.wikipedia.org/wiki/Adaptive_replacement_cache
> - при желании почитать и понять).
> Еще раз - никакого копирования данных не происходит

Точнее - солярка скипает page cache при обращении к ARC, используя page cache только для страниц приложения. Сделано было из-за того, что механизмы солярки не позволяли нормально организовать zero-copy между двумя кэшами. *BSD юзают копирование между кешами - на странице нагуляла на лж четко видно, как падает производительность от отсутствия zero-copy. Linux не рассматриваем, поскольку BTRFS корректно юзает системный кеш, и никаких проблем с этим не имеет.

> просто страницы с данными находятся одновременно в ARC и LRU кэше

Пруф в студию - большинство "пейсателей" этот момент обходят стороной во всех презентациях и статьях. "Забывают", видимо.

> А доп расходы по памяти это немного другое, это куча служебных структур
> - для того что бы держать COW и версионные изменения.

Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности? Архитектура, дружище, архитектура.

> кроме того у него очень затянутый комит изменений на диск -
> И это никак не связано с ARC кэшем который там внутри...

Взаимоисключающие параграфы.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..., opennews, 26-Окт-12, 18:53  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру