= Сообщение: 5549 из 10757 ===================================== RU.UNIX.BSD =
От : Alex Korchmar 2:5020/400 20 Apr 17 14:52:42
Кому : Nikolay Linkevich 20 Apr 17 14:52:42
Тема : Re: кеш zfs на SSD
FGHI : area://RU.UNIX.BSD?msgid=<1187507216@ddt.demos.su>+619977f1
На : area://RU.UNIX.BSD?msgid=2:5023/24.3193+79b4fa3f
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=2:5023/24.3193+79b9c062
==============================================================================
From: Alex Korchmar <noreply@linux.e-moe.ru>
Nikolay Linkevich <Nikolay.Linkevich@p3193.f24.n5023.z2.fidonet.org> wrote:
NL> :offtop on
NL> Советую не бросаться громогласными заявлениями, т.к. ты не знаешь, кто я,
мне феерически начхать на то, кто ты.
NL> а выводы делаешь.
по твоей писанине.
NL> Так вот, я знаю как работает SSD с ZFS, а freenas, которая
я пока не вижу демонстрации этих знаний.
NL> отнюдь не чистая фряха (GENERIC), априори может(!) иметь определенные
то есть почитать - конечно же, нет - сразу рассказывать сказки.
(к тому же, конечно же, его писали рептилоиды, и специально сделали так,
чтобы как именно NAS он работал как можно хуже)
Так вот, специально для тебя: там (в том что надо читать, разумеется)
нет никаких специальных особенностей фринаса (если бы были, их стоило бы,
вообще-то, копировать) - просто объясняются ключевые
для понимания как все это работает вещи, мягко говоря, неочевидные
(иногда вообще контринтуитивные), поскольку они и их пользователи уже
наступили на все возможные и большинство невероятных грабель в этой
области.
NL> В официальной(!) документации сказано, что если нет данных в ARC,
NL> то ZFS ищет их в L2ARC и только потом на диске.
да, было бы странно их там не искать, и что с того?
NL> P.S. По своему опыту работы с СХД я советую юзать SSD под кеш.
опыт без знаний и умения поставить чистый эксперимент - увы, ничто.
(равно как - основанные на узкоспециальном опыте широковещательные
заявления без указания этой специфики)
NL> К тому же мой случай с ZFS это бюджетная СХД для резервного ДЦ, где
NL> распологается одна из нод ESXi кластера и куда реплицируется часть
NL> однотипных виртуалокс(vReplication). До кучи там же будет стоять вторая
NL> такая же для второго хранилища бекапов, чтобы в случае сбоя или достать
NL> бекапы или запустить Instant VM Recovery. Прогретый кеш там
NL> будет ой как нужен, ибо для критического сегмента КД у нас 0,98
то есть на самом деле ты мог бы выбросить эту хранилку целиком, и
обойтись просто одним ssd-диском (пусть зарезервированным, неважно).
Оставшиеся 2% пожав или переложив на отдельный медленный сторадж,
как и все остальное.
Да, в этом случае, безусловно, кэш работает, более того, он,
действительно, именно для такой ситуации предназначен.
К сожалению, большинство из нас используют хранилки несколько иначе -
и никакой пользы от него не получит, получит сплошные потери, поскольку
сперва мы будем читать вращающиеся диски, медленно и печально, потом -
"быстро", но совершенно ненужно для пользователя - записывать прочитанное
в кэш.
Потом, теоретически, мы могли бы прочитать это еще раз из кэша, но
практически - вряд ли это write-only хранилка, и вряд ли размер кэша
равен размеру хранилки - поэтому мы просто будем читать что-то другое,
вымывая предыдущее - опять с потерями производительности на ненужную
перезапись.
(надеюсь, не надо объяснять, почему для L1 такой проблемы нет, и
его наращивание всегда улучшает ситуацию, кроме совсем клинического
случая linear read чего-то всегда большего чем кэш ? ;-)
Почему в твоем случае это тоже неудачное решение - тоже надо разжевать?
Ок: поскольку кэш вряд ли равен размеру хранилки, _любое_ обращение к
чему-то за пределами твоих 98% - портит производительность системы в разы,
и совершенно непредсказуемым образом. Очевидно, что если скорость чтения
твоих виртуалок для тебя важна - гораздо эффективнее держать их на ssd,
а бэкапам позволить дрыгать дисками столько, сколько им понадобится.
При это гораздо легче уследить за ситуацией, когда этот ssd кончится,
чем за ситуацией, когда из-за разрастания виртуалок кончится красивый
результат попадания в кэш, потому что это может стать заметно далеко
не сразу.
> Alex
--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)
|
