Почему скорость записи на том lvm, с которого сделан снапшот падает в несколько раз?

Грубо говоря: старые версии обновленных блоков скидываются в снапшот. Из-за этого на одну операцию записи на самом деле приходится две.

То есть снапшот актуален не только в момент создания, но и всё время его жизни?

снапшот и есть шот - снимок. Что значит актуальные, типа что у тома, что у снапшота данные одинаковы? зачем тогда снапшоты нужны?

Снимок актуален на время его создания, естественно.

Снимок актуален на время его создания, естественно.

Тогда я снова не понимаю откуда падение скорости записи в разы?

Грубо говоря: старые версии обновленных блоков скидываются в снапшот. Из-за этого на одну операцию записи на самом деле приходится две.

Снапшот уже создан, например вчера, уже даже копию с него сняли, всё больше его не трогаем, но и не удаляем. Но скорость записи на lvm, с которого снапшот сделан всё равно, всё время с момента создания снапшота, в 5 раз ниже, по сравнению с тем же томом до снятия снапшота.

LVM сам по себе такой корявый.

Да просто все:

После создания снапшота новые блоки пишутся на том, но (для поддержания снапшота в состоянии на момент его создания) еще и копия немодифицированного блока уходит и на раздел снапшота. И так до момента удаления.

http://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html

но (для поддержания снапшота в состоянии на момент его создания) еще и копия немодифицированного блока уходит и на раздел снапшота.

Что значит «поддержания снапшота в состоянии на момент его создания»? Снапшот, как тут верно заметили, это состояние раздела на момент снятия снапшота и мы его уже сняли. Чего там поддерживать то?

P.S. за ссылку спасибо, но я это уже читал.

ты создаешь снапшот и он пустой. а изменяемые блоки тома как раз и пишутся на снапшот. Думаю, как то так.

ты создаешь снапшот и он пустой.

Не пустой он, с него сразу можно бэкап делать.

Снятие == создание

Поддерживать надо, т.к. создание снапшота не есть копирование всей файлухи в новый раздел. Создание - всего лишь маркировка момента, когда его создали и указание, что дальнейшая модификация ФС должна приводить к копированию оригинального блока на снапшот-раздел (он для того и подсовывается).

Что тут непонятного-то?

Так. Например файлуха 2 Гб. Мы делаем снапшот на раздел в 100 Мб. Бэкапим себе тихонько и прибиваем снапшот.

Т.е. ЕСЛИ объем измененных блоков на исходной файлухе не превысит где-то 100 Мб, ТО такое сработает. (Что будет, если объем будет превышен я не знаю, не задавался вопросом).

Тебе файлуху показывают, только подставив копии блоков из снапшот-раздела. (Которые туда попали после модификации на оригинальной ФС)

Нельзя-ж так тупить-то!

Поддерживать надо, т.к. создание снапшота не есть копирование всей файлухи в новый раздел. Создание - всего лишь маркировка момента, когда его создали и указание, что дальнейшая модификация ФС должна приводить к копированию оригинального блока на снапшот-раздел (он для того и подсовывается). Что тут непонятного-то?

Понятно, в снапшот просто скидываются оригинальные данные на момент создания снапшота, до их изменения на томе.

Что будет, если объем будет превышен я не знаю, не задавался вопросом

Снапшот автоматом удалится.

P.S.Спасибо, всё понятно разжевал.

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

А еще бывает весело, когда место в спецобласти кончается..

На UFS2 и ZFS таких проблем нет.

И это, безусловно, прекрасно, но у меня нет возможности использовать FreeBSD.

Опять, блин... Реклама- такая реклама.

Человек про LVM конкретно спрашивал.

За ZFS не скажу, а на UFS2 отличие в том, что создают на свободном пространстве битмаски неперезаписанных блоков. А пишут не поверх блока, а в свободное место.

На LVM снапшоты ФС-независимы. На UFS2 - жестко привязаны к структуре ФС.

почему?

Сказывается уровень реализации — на файловых системах снапшоты почему-то легче поддерживаются, чем на блочных (виртуальных) устройствах. Видимо, важную роль играет степень информированности о действиях с файловой системой того уровня, на котором выполняется снапшот.

На BtrFS тоже.

Я добавлю:

Снапшот на уровне девайса - copy-on-write (прочитали, сделали копию, записали новое). Зато очень быстро создается.

Снапшот на уровне FS - сначала создание области метаданных для снапшота (Для UFS и большого количества файлов и битмапов - оооочень медленно). Потом работа с изменением FS отличается от нормальной - «старые» блоки данных не переписываются - аллоцируются новые. Плюс ОС не лезет в область копии метаданных снапшота. Как результат - скорость записи практически не отличается от оригинала. Только небольшой оверхед на пометки в области битмапов собственно FS или снапшота (тут уже от реализации зависит).

http://zfsonlinux.org/

Гоняю дома. Работает...

Так. Например файлуха 2 Гб. Мы делаем снапшот на раздел в 100 Мб. Бэкапим себе тихонько и прибиваем снапшот.

Можно вопросец (может оказаться немного глупым).

Вот снимок размером в 100 мегабайт всю информацию ФС 2 гигабайт не содержит, это понятно... А вот когда мы делаем резервную копию этого снимка (и потом его удаляем) - он копирует только эти 100 мегабайт или 2 гигабайта целиком?

То есть, к примеру, после удаления снимка восстановить то мы что-то сможем из копии?

Вот снимок размером в 100 мегабайт всю информацию ФС 2 гигабайт не содержит, это понятно...

На снимке - только информация, связанная с изменениями. И бэкапим мы реальную файловую систему без изменений - на файловой системе измененные и неизменные блоки, а копии «старых» блоков попадают в раздел снапшота. Прибэкапе - не изменившиеся блоки берутся из раздела самой FS, копии старого состояния изменившихся блоков - из раздела снимка.

То есть, к примеру, после удаления снимка восстановить то мы что-то сможем из копии?

После удаления снимка информации о «старом» состоянии системы больше нет. Только реальная живая фалуха.

Вы как-то туманно на мой вопрос ответили, я так и не понял...

Ответьте проще! вот есть 10 гигабайт раздела, 100 мегабайт весит снимок (пусть).

я делаю резервную копию этого снимка... и снимой удаляю. резервная копия весит 100 мегабайт или 10 гигабайт?

В чём профит всех этих снимков, чем это лучше обычного tar?

и снимой удаляю. резервная копия весит 100 мегабайт или 10 гигабайт?

Если была забита вся файлуха, то 10 гигабайт.

В чём профит всех этих снимков, чем это лучше обычного tar?

Во время бэкапа никто не перепишет файл. Снимок - состояние ФС на данную секунду.

Снапшот это фиксированная точка состояния ФС на момент снимка. То есть ты обращаешься к той же ФС, но зафиксированной (со сбросом буферов). Размер снапшота определяется количеством изменившихся блоков с момента фиксации. Когда том, имеющий снимок, изменяется, «отснятые» блоки копируются в устройство снимка, чтобы сохранить состояние. То есть оригинальный том не заморожен и изменяется, и когда ты удаляешь снимок, то теряешь замороженное состояние, тогда как оригинал уже находится в актуальном состоянии.

Надеюсь, понятно получилось %)

В чём профит всех этих снимков, чем это лучше обычного tar?

Оно не лучше, оно дополняет. Ты точно так же пользуешься tar, но уже уверен, что в архиве не окажется файл, который кому-то вздумалось перезаписать в тот момент, когда он копировался.

Всё, теперь понял. Спасибо. примерно так и думал.

Теперь понятно, откуда тормоза и в чём профит =)