Am
и на этом всё
Size: a a a
2021 October 22
Am
собоственно поэтому я и послал туда где обещали починить то что не существует )
Am
но коллега не может увидить суть в ответет )))
DP
не очень себе представляю монструозность поделия при реализации 🙂 особенно с репликацией кэша
DP
это вообще какой то нонсенс
ВН
А кстати интересная вещь - реплицируемый консистентный кэш
ВН
Ну т.е. интересно даже как они его обычный к rbd применяют
SP
Саша, я так понимаю, у вас задача просто выговориться вне контекста смысла диалога?
Вам фраза replicated write log ни на что не намекает?
Вам фраза replicated write log ни на что не намекает?
ВН
Это ж надо типа по идее сохранить дословно точно тот же порядок записи
Am
Сергей приведите пример реализации )
ВН
Т.е. прям буквально, чтобы любой запрос записи A2, начавшийся после завершения A1, и реплицировался после завершения репликации A1
Am
кроме вот того концепта который в слайдах
SP
Вы гляньте презу, там все описано.
Для PMEM все изначально делалось, потому что там быстрее и проще было реализовать на базе PMDK, плюс эту фичу делал Интел, им нужно свои железки продавать.
Для PMEM все изначально делалось, потому что там быстрее и проще было реализовать на базе PMDK, плюс эту фичу делал Интел, им нужно свои железки продавать.
SP
Я не хочу вступать с вами изначально в бессмысленную беседу, вы пытаетесь флеймить и цеплять ради повышения своего ЧСВ, я же пытаюсь найти ответ на интересующий меня вопрос.
Е
Я извиняюсь, а почему бы просто не использовать на ноде bcache, а при миграции не переключать его во врайт-тру и не дожидаться состояния clean?
SP
Не стоит извиняться, вы ничего не сделали.
Что вы подразумеваете под нодой? Нода(ы) осд или нода с рбд?
Что вы подразумеваете под нодой? Нода(ы) осд или нода с рбд?
Е
Нода с RBD
Е
то есть, bcache стоит между RBD и виртуалкой
ВН
Видимо у вас там плодотворная дискуссия в списке рассылки была
ВН
С коллегой =))