естественно. но аналогии не могут на сто процентов совпадать. на то они и аналогии.

Так, я попросил бы :) У инфинидат кеш на запись заметно меньше кеша на чтение и такой большой (в абсолютных цифрах) он нужен только для того, чтобы подержать данные в нем подольше, чтобы проанализировать паттерны обращения к ним. А так поскольку инфинидат тоже может писать всегда полными страйпами, особых проблем при сливе на диски нет. Очень большой кеш на запись ведет тоже к своим проблемам - например нужны огромные батарейки чтобы его гарантировано сбросить на диски

А с nvram и кеш - вы бы сначала о терминах договорились что ли

Плюс его надо успевать быстро зеркалить

вот тут как раз размер и nvram и кэша никак не влияет.

тут размеры пофиг, это же постоянный процесс. А вот если что-то сломалось и его надо перезеркалить - вот тут размер имеет значение

Да без разницы на самом деле. Можно NVRAM как термин из дискуссии убрать.

это было в предыдущих сериях. ram = cache, nvram=nvram

Скорость записи в оперативную память не даёт сколько нибудь заметного оверхеда в случае с схд, поэтому накладные расходы на копирование блоков в nvram из системной памяти в случае очень малы

А ну да, не подумал.

Василий, это не упрёк был, просто факт того что у вас объёмы кэша выше чем у многих других вендоров)

Что опять подтверждает, что узкое место не размер кэша на запись, а цпу и диски. Если в фигачить ещё больший объём кэша, а процессор не будет успевать посчитать патерны, то в итоге кэш буде забит, данные не будут сброшены.
Это конечно утрированная ситуация, в таких случаях скорее всего забивают на оптимизацию и сливают на диски как есть.

Николай, внимательнее пожалуйста, если nvram занят до конца, а кэш не до конца, тогда у тебя nvram начинает влиять на производительность. Повторюсь. Дело не в оверхеде, а в ожидании ack от nvram.

Да я понимаю :) Но тут в целом дело такое - если у вас бекенд в принципе не успевает переварить поток на запись, то увеличением кеша на запись этому не поможешь. Может какие-то пики он позволит отловить, но в устоявшемся режиме фиг

я именно это и пытаюсь коллегам донести.

Вы видимо не читаете то что я пишу.. не вижу смысла спорить. Как только вы поймёте для чего нужен nvram у нетапа, все вопросы будут сняты

я знаю, для чего он нужен.
речь сейчас о том, на что он может или не может влиять. Менторский тон прошу отставить.

Я делаю выводы из ваших постов, не более...

Какие-то пики это такая бессмысленная ситуация в реальной жизни. Никто не берет СХД, чтобы два раза в сутки у нас 1% записи прошёл в 10 раз быстрее, а все остальное время СХД тупила и не справлялась из-за бэкенда

так и с nvram тоже - если wafl не успевает сбросить из буфера на запись на диски, то увеличением nvram вы конечно чего-то улучшите, но sustained ситуация не изменится особо