Я знаком с тем, для чего предназначен BBWC (кэш записи с батарейным питанием), и ранее использовал их на своих серверах даже с хорошим ИБП. Есть очевидные сбои, для которых он не обеспечивает защиту. Мне любопытно понять, действительно ли это дает какую-то реальную пользу на практике.
(Примечание: я специально ищу ответы от людей, у которых есть BBWC и у которых были сбои / сбои и помогло ли BBWC восстановлению или нет)
Обновить
После обратной связи я все более скептически отношусь к тому, добавляет ли BBWC какую-либо ценность.
Чтобы иметь какую-либо уверенность в целостности данных, файловая система ДОЛЖНА знать, когда данные были переданы в энергонезависимое хранилище (не обязательно диск - момент, к которому я вернусь). Стоит отметить, что многие диски лгут о том, когда данные были переданы на диск ( http://brad.livejournal.com/2116715.html ). Хотя кажется разумным предположить, что отключение кеша на диске может сделать диски более честными, все еще нет гарантии, что это так.
Из-за типично больших буферов в BBWC барьер может потребовать значительно больше данных для фиксации на диск, что приводит к задержкам при записи: общий совет - отключать барьеры при использовании энергонезависимого кэша обратной записи (и отключать кеширование диска). Однако это может подорвать целостность операции записи - просто потому, что в энергонезависимой памяти хранится больше данных, это не означает, что она будет более согласованной. Действительно, возможно, без разграничения между логическими транзакциями, кажется, меньше возможностей для обеспечения согласованности, чем в противном случае.
Если бы BBWC должен был признать барьеры в тот момент, когда данные попадают в его энергонезависимое хранилище (а не записываться на диск), то он, по-видимому, удовлетворял бы требованию целостности данных без снижения производительности - подразумевая, что барьеры все еще должны быть включены. Однако, поскольку эти устройства обычно демонстрируют поведение, совместимое с сбросом данных на физическое устройство (значительно медленнее с барьерами) и широко распространенными рекомендациями по отключению барьеров, они не могут вести себя таким образом. ПОЧЕМУ БЫ НЕТ?
Если ввод-вывод в ОС моделируется как последовательность потоков, то есть некоторая возможность минимизировать эффект блокировки барьера записи, когда кэширование записи управляется ОС - поскольку на этом уровне только логическая транзакция (один поток) ) нужно быть преданным. С другой стороны, BBWC, не зная, какие биты данных составляют транзакцию, должен будет зафиксировать весь кэш на диске. Чтобы ядро / файловые системы действительно реализовали это на практике, потребовалось бы гораздо больше усилий, чем я готов инвестировать в данный момент.
Комбинация дисков, сообщающих выдумкам о том, что было совершено, и внезапная потеря питания, несомненно, приводит к повреждению - и с файловой системой с журналированием или структурированным журналом, которая не выполняет полный fsck после сбоя, маловероятно, что повреждение будет обнаружено, не говоря уже о том, что сделана попытка его починить.
Что касается режимов сбоев, то, по моему опыту, наиболее внезапные перебои в подаче электроэнергии происходят из-за потери сетевого питания (легко устраняется с помощью ИБП и управляемого отключения). Люди, вытаскивающие неправильный кабель из стойки, подразумевают плохую гигиену центра обработки данных (маркировка и прокладка кабеля). Существуют некоторые типы внезапных потерь мощности, которые не предотвращаются ИБП - сбой в блоке питания или VRM BBWC с барьерами обеспечит целостность данных в случае сбоя, однако, насколько распространены такие события? Очень редко судя по отсутствию ответов здесь.
Безусловно, перемещение отказоустойчивости выше в стеке значительно дороже BBWC, однако реализация сервера в виде кластера имеет много других преимуществ для производительности и доступности.
Альтернативный способ смягчить влияние внезапной потери питания - внедрить SAN - AoE делает это практическим предложением (я не вижу смысла в iSCSI), но опять-таки это более высокая стоимость.