- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет!
Возможно кому-то будет интересен наш проект по реализации read-only версии утилиты для чтения дисков в формате OpenVZ ploop на любом ядре: https://github.com/FastVPSEestiOu/ploop_userspace
Написано на С++, компилируется почти везде, поддерживает как ploop v1, так и ploop v2.
Зачем оно может пригодиться? Например, извлечь содержимое диска на машине без OpenVZ ядра или смонтировать блочное устройство на удаленной машине, чтобы выполнить инкрементальный бэкап.
Версия с поддержкой записи, полагаю, реализуема, но пока мне, честно говоря, очень страшно лезть в формат хранения, так как механизмы выделения блоков BAT и их ремаппинга мне не совсем понятны.
Pavel.Odintsov, Отличная утилита, спасибо Павел
Pavel.Odintsov, Отличная утилита, спасибо Павел
Спасибо за спасибо :)
Действительно, спасибо за утилиту.
Но вопрос смежный - активно в продакшене используте у себя ploop? По производительности в целом и производительности бэкапа это лучше традиционного решения?
Glueon, лучше в обоих случаях, но очень требовательно к работе железа - то есть ECC, RAID с батарейкой, хорошо резервированное питание - нужно обязательно. А также, разумеется, никаких flashcache/bcache и прочих - убьет данные, почти гарантированно.
Pavel.Odintsov, не понятна суть явления. каким именно образом данные приходят в негодность ?
Всем привет!
Возможно кому-то будет интересен наш проект по реализации read-only версии утилиты для чтения дисков в формате OpenVZ ploop на любом ядре: https://github.com/FastVPSEestiOu/ploop_userspace
Написано на С++, компилируется почти везде, поддерживает как ploop v1, так и ploop v2.
Зачем оно может пригодиться? Например, извлечь содержимое диска на машине без OpenVZ ядра или смонтировать блочное устройство на удаленной машине, чтобы выполнить инкрементальный бэкап.
Версия с поддержкой записи, полагаю, реализуема, но пока мне, честно говоря, очень страшно лезть в формат хранения, так как механизмы выделения блоков BAT и их ремаппинга мне не совсем понятны.
садись, браза, пять!
и за чтение спасибо.
---------- Добавлено 15.09.2014 в 19:07 ----------
Pavel.Odintsov, не понятна суть явления. каким именно образом данные приходят в негодность ?
netwind, Паша, хайль! как дела ?
ТС, тот же вопрос кстати
Pavel.Odintsov, не понятна суть явления. каким именно образом данные приходят в негодность ?
ploop - очень простой формат, в нем нет журналирования, нет бэкапа суперблока (BAT). А суперблок - это кусок данных в начале диска в 1Мб.
Если туда будет идти запись и в это время вырубится питание, то он повредится и вся тушка придет в негодность, так как только в BAT хранится маппинг между виртуальными секторами и реальным их положением в образ-файле.
Как воркэраундом может быть вариант - бэкапить суперблок самостоятельно или, в иделае, бэкапить тушки целиком, всегда.
Угу, вот только что имел радость в виде убитого lvm на котором были плупы
LVM собрался, плупы - нет
Да, ситуацию еще может усугубить fsck. Он может решить пойти подправить немного экстентов, на которых лежит ploop, а так как это не простые файлы, для которых повреждение нескольких блоков можно пережить - все разлетается.
Если туда будет идти запись и в это время вырубится питание, то он повредится и вся тушка придет в негодность, так как только в BAT хранится маппинг между виртуальными секторами и реальным их положением в образ-файле.
не понятно почему именно кеши усиливают вероятность, а хардверные рейды нет. Вы же не читаете данные в обход кешей ? Если flashcache сделан как устройство dm, как вообще можно прочитать мимо ? там же почти всегда что-то несовместное.
Или дело только в том, что с кешами плотность размещения VPS еще больше и операций записи больше?