LINUX.ORG.RU

CoW или не CoW, вот в чем вопрос

 , , , ,


1

5

Сейчас появилось некоторое количество файловых систем, которые почему-то необоснованно относят к группе CoW (Copy-on-Write). Почему так получилось, и что что на самом деле есть Copy-on-Write?

Итак, начнем.

Механизм Read-Modify-Write

Для начала, мы разберем что такое RMW (Read-Modify-Write). Представим себе, что в нашей файловой системе каждый экстент данных должен иметь метаданные (для простоты, скажем что это контрольная сумма). Это классическое устройство механизма хранения данных контроля целостности в таких ФС как ZFS или BTRFS. При этом, размер экстента достаточно большой (16 … 64КБ), а ввод-вывод идет малыми блоками (4КБ).

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

В этот момент у нас и возникает то, что называется Read-Modify-Write: прочесть весь экстент (Read), изменить его в середине (Modify), просчитать новую контрольную сумму и выполнить запись экстента целиком (Write).

То есть RMW это механизм, используемый во всех случаях, когда для выполнения запись нужны дополнительные данные (собсвтенно, весь экстент), хранимые за границами модифицируемого блока.

Redirect-Write

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

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

Такой механизм используется в BTRFS и ZFS.

Таким образом, ZFS и BTRFS это не CoW а сочетание RMW + Redirect-Write. Ну или просто просто Redirect-Write.

Именно наличие Redirect-Write позволяет реализовать снапшоты малыми затратами производительности - достаточно просто старое место не освобождать, а оставить числиться как занятое снапшотом.

Таким образом, Redirect-Write используется как механизм обеспечения как регулярной записи, так и клонирующей записи.

Copy-on-Write

Классический механизм Copy-on-Write работает только для снапшотов или клонов. Он работает похоже на Redirect-Write, но с очень существенным отличием - новые данные пишутся в исходное место, а старые данные (копия) записываются в новое (пустое) место.

При этом, сначала случается Read экстента, затем Copy (запись исходной копии в новое место) и затем Write - запись измененных данных (не обязательно экстента целиком) в изначальное место. И если нам надо обеспечить атомарность записи, нам придется прибегать к дополнительным механизмам (например журналированию).

Так работают снапшоты LVM.

CoW - механизм старый и появился в те времена, когда выбирая между производительностью и возможностью некоторой неконсистентности данных в очень-очень редких случаях, выбирали производительность, задач поддержки большого количества версий/снапшотов не стояло, а сам снапшот предполагался как короткоживущая сущность на время бэкапа или каких-то работ.

Заключение

Если подытожить всё то, что было описано выше, то становится понятно, что:

  1. Механизм CoW является технически более простым, может быть включен и отключен при необходимости, но платой за эту простоту будут потенциальные проблемы с целостностью данных и атомарностью записи в граничных случаях.

  2. Redirect-Write позволяет достичь того же результата, что и CoW, но при этом обеспечивает лучшую надежность и гарантию записи, но требует существенно больше ресурсов - особенно для регулярной (обычной) конвенционной записи.

  3. Называть ZFS и BTRFS Cow-based файловыми системами некорректно - они не CoW, они Redirect-Write. Они дают те же самые возможности, но они работают по совершенно другим принципам, но при этом потребляют намного больше ресурсов при обычной записи.

  4. Если вам нужна быстрая обычная запись и снапшоты и клоны редки и короткоживущи - ваш выбор Copy-on-Write (LVM). Если снапшоты и клоны для вас скорее постоянное состояние - ваш выбор Redirect-Write (ZFS и BTRFS).

★★

Проверено: Dimez ()
Последнее исправление: hobbit (всего исправлений: 3)

По п.4 Заключения, хотелось бы уточнить, XFS подойдёт?

utanho ★★★★★
()

в целях улучшения призводительности советуют nodatacow для btrfs

monkdt
()

Не раскрыта тема сколько места надо под EFI раздел, сколько под / и что делать, когда в хомяке закончится место.

vvn_black ★★★★★
()
Ответ на: комментарий от vvn_black

федора отдает 600 мб под efi по умолчанию при установке

monkdt
()
Ответ на: комментарий от vvn_black

Не раскрыта тема сколько места надо под EFI раздел

Fedora (и RHEL-клоны) использует 600Mb для /boot/efi. Для дуалбута, полагаю, 1G будет нормальным.

MoldAndLimeHoney
()
Последнее исправление: MoldAndLimeHoney (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

Если серьёзно - да, безопасно. Если не RAID5/6 - они в btrfs мертвы.

anonymous-angler ★☆
()
Ответ на: комментарий от MoldAndLimeHoney

Нет. Опасно. оно сырое и сделано через жопу

Pinux001
()

может быть включен и отключен при необходимости,

Как отключить cow в openzfs ? или это наброс такой ?

Pinux001
()
Ответ на: комментарий от Pinux001

Но есть один нюанс - чтобы удалить файл в ZFS или BTRFS, вам нужно… Свободное пространство! Для записи новых версий метаданных, хаха. А redirect write требует свободного места для любого изменения - даже для удаления

no-dashi-v2 ★★
() автор топика
Последнее исправление: no-dashi-v2 (всего исправлений: 1)

про производительность бтрфс с nodatacow не я сам сочинил. Вот один совет из многих

https://www.ucartz.com/clients/knowledgebase/1248/How-to-Tune-Btrfs-Filesystem-for-Better-Performance.html

nodatacow — не копировать данные при записи. datacow используется для обеспечения того, чтобы пользователь имел доступ либо к старой версии файла, либо к более новой версии файла. datacow гарантирует, что на диск никогда не будут записаны частично обновленные файлы. nodatacow дает небольшой прирост производительности за счет прямой перезаписи данных (например, ext[234]) за счет потенциального частичного обновления файлов при сбоях системы. Прирост производительности обычно составляет < 5%, если рабочая нагрузка не связана с случайной записью в большие файлы базы данных, где разница может стать очень большой.

monkdt
()

Интересная статья, чувствуется опыт. Теперь вопрос к практикующим: а как часто вы вообще используете снапшоты?

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

Но это глубоко системная штука, которую не делают каждый день и просто так.

А у вас для чего и как часто используются снапшоты?

alex0x08 ★★★
()
Ответ на: комментарий от vvn_black

Хватит и 20 мб, нормальные загрузчики умеют хранить ядро в корне. Если использовать EFISTUB или говнецо по типу systemd-boot - то полгига хватит вполне.

Werenter ★★★
()
Ответ на: комментарий от no-dashi-v2

xfs получила cow вот буквально совсем недавно. Несмотря на это позиционировалась редхатом как суперпупер. Но кто я такой чтобы спорить с поляками-токенами?

monkdt
()

Если вам нужна быстрая обычная запись и снапшоты и клоны редки и короткоживущи - ваш выбор Copy-on-Write (LVM).

Клоны редки и долгоживущи – мой выбор rescuezilla, а ваши лвмы и бтрсы в гробу я видал.

papin-aziat ★★★★★
()
Ответ на: комментарий от vvn_black

что делать, когда в хомяке закончится место

У тебя отдельный хомяк!? Ну ты ваще отсталый чел.

papin-aziat ★★★★★
()
Ответ на: комментарий от alex0x08

а как часто вы вообще используете снапшоты?

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

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

Не вижу смысла стесняться спамить снапшотами, раз могу.

если правильно помню в Солярисе системные апдейты так и работают через снапшоты ZFS до сих пор.

Верно. Ну и в openindiana, как минимум, делаются снимки при каждом изменении, даже при обновлении репозитория. Кроме того, эти снапшоты и разворачиваются в отдельную загрузочную среду.

Clockwork ★★★★★
()
Ответ на: комментарий от Clockwork

Плановые каждый день делаю того устройства, на котором работаю – будь-то десктоп или ноут,

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

alex0x08 ★★★
()
Ответ на: комментарий от alex0x08

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

Обычно такие вещи храню не на рабочей ОС, а стараюсь сразу закидывать на файлопомойку, которая тоже бекапится соответствующе ей настроенным образом. :D Ну либо оно будет удалено после просмотра, а значит и не нужно снапшотить :D

На файлопомойке (как и на ОС при создании снапшота) снапшот занимает места нисколько. Дальше он увеличивается только по мере изменения данных.

Кроме того, репликация льется инкрементально, что вносит только новые изменения.

Про хранение этих снапшотов на сервере – у меня никогда еще не забивалось всё место снапшотами.

Clockwork ★★★★★
()
Последнее исправление: Clockwork (всего исправлений: 1)
Ответ на: комментарий от Clockwork

Обычно такие вещи храню не на рабочей ОС

Я образно, сейчас же все что не скачаешь - все большое. Что образы ОС, что торренты что репозитории.

Дальше он увеличивается только по мере изменения данных.

К чему я и веду, папка «Downloads» как раз и дает такие скачки.

alex0x08 ★★★
()

и затем в метаданные производится атомарная запись, включающая в себя новую контрольную сумму и новое расположение экстента

CoW происходит вот здесь.

intelfx ★★★★★
()
Ответ на: комментарий от alex0x08

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

Во FreeBSD почти так же (там используются клоны), если система установлена на ZFS и используется ZFSBE (дефолт). Из солярки и слизали. ☺

А у вас для чего и как часто используются снапшоты?

Бэкап/репликация, перенос данных, клоны. Регулярно.

mord0d ★★★★★
()
Последнее исправление: mord0d (всего исправлений: 1)
Ответ на: комментарий от intelfx

Это не CoW, а тот самый классический redirect write - просто он производится по методике R-M-W потому что операцию нужно выровнять по блоку аллокации.

no-dashi-v2 ★★
() автор топика

Ты какие-то свои (может, ещё чьи-то) понятия пытаешься выдать за всеобщую истину. То, что ты называешь «cow» (когда старые данные куда-то копируются, это ж каким извращенцем надо быть такое придумать, впрочем за LVM я не удивлён) я вообще вижу первый раз, а то, что у тебя «RMW с отдельными метаданными» - это и есть то, что большинство людей подразумевают под cow. И касается это не только и не столько даже файловых систем, а в первую очередь управления виртуальной памятью в современных ОС.

Так что да, zfs именно cow, в общепринятом смысле этого слова.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от papin-aziat

у меня на сервере, на шаре для коллективной работы, каждые 30 минут проверяется, были ли изменения в файлах и если да, то делается снэпшот. Снимки не удаляются, по крайней мере, в течении года.

Такой механизм уже несколько раз позволил спасти крайне важные вещи и один раз дать по голове некоему «вредителю».

Как бонус, инкрементальный бэкап оказывается тривиальной операцией.

Ну и на «шифровальщики» покласть с высокой колокольни.

glebiao
()
Ответ на: комментарий от alex0x08

а если например пару фильмов скачать (это же десктоп)? Что-то большое ведь тоже поедет в снапшот? Или возможны какие-то ограничения по размеру для таких случаев?

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

Т.е. в случае фильмов нужно создать сабвольюм @Downloads, монтировать его в /home/user/Downloads и не делать его снапшоты.

То же самое для директории Стима, например.

MoldAndLimeHoney
()
Последнее исправление: MoldAndLimeHoney (всего исправлений: 2)
Ответ на: комментарий от MoldAndLimeHoney

Т.е. в случае фильмов нужно создать сабвольюм @Downloads, монтировать его в /home/user/Downloads и не делать его снапшоты.

И молиться чтобы ничего большого за папку Downloads не складировали. Но идею понял, да.

alex0x08 ★★★
()

ставя в qemu что-нибудь для дела/на посмотреть сразу выбираю raw ибо qcow2 только для ынтерпрайза.

mrjaggers
()
Ответ на: комментарий от no-dashi-v2

Какой ещё rtfm? Я тебе сообщил, что понимают под cow подавляющее большинство людей, использующих этот термин, в т.ч. специалистов. Если в каком-то мануале IBM используется их оригинальное понимание этого слова - это их дело, на общую ситуацию это не влияет.

firkax ★★★★★
()
Ответ на: комментарий от firkax

А еще большинство под словом интернет понимает браузер и гугл, под словом программист понимают даже QAшника и вообще любого кто может переустановить винду с умным видом, под словом облако понимают хранение фоточек и просит назначить антибиотики от гриппа. Но тот факт, что их «большинство» не означает что они правы.

Те кто занимаются стораджами профессионально несколько больше в теме. Возьмем для примера Dell (им принадлежит EMC например - не исключено что ты слышал о такой компании и в курсе чем они занимаются) и они также разделяют COW/ROW - https://infohub.delltechnologies.com/l/dell-emc-powermax-and-vmax-all-flash-timefinder-snapvx-local-replication-1/redirect-on-write

Но они конечно не авторитеты, подумаешь - ну вот писали несколько десятков лет стораджи и так ничему и не научились, то ли дело лоровские эксперты.

no-dashi-v2 ★★
() автор топика

Если мне нужно - я куплю что-нибудь с поддержкой WAFL'и и не буду парить себе моцк.

windows10 ★★★★★
()
Ответ на: комментарий от firkax

это и есть то, что большинство людей подразумевают под cow

Так что да, zfs именно cow, в общепринятом смысле этого слова.

А давайте называть вещи своими именами, а не подразумевать и иметь в виду. Это ведь даже не гуманитарный подход, а скорее блондинистый.

utanho ★★★★★
()
Ответ на: комментарий от utanho

Это и есть «своими именами». COW означает «создавать копию при записи» (хотя я согласен, что тут не уточняется, копия эта для новых данных или для старых, но везде кроме странных мест - делается для новых). Если кто-то хочет то же самое (а может и не то же, а то же с уточнениями) называть ещё и «redirect-write» - пусть называют, но красть общепринятый термин copy-on-write и придумывать ему другой смысл не надо, даже если ты крупная корпорация, пишущая какие-то мануалы.

Итого, cow это «копировать при записи», есть нормальный повсеместно используемый cow где при изменении блока новые данные пишутся в новое место, есть (если верить автору, а я не уверен что это следует делать) извращенский cow где делается ещё одна лишняя запись блока (и не знаю сколько перезаписей метаданных) чтоб в копии были старые данные, а новые - на месте старых.

firkax ★★★★★
()
Ответ на: комментарий от alex0x08

в Солярисе системные апдейты так и работают через снапшоты ZFS до сих пор

Boot Environments: https://illumos.org/man/8/beadm https://man.freebsd.org/cgi/man.cgi?query=bectl

В linux/openzfs не знаю есть ли подобный функционал.

А у вас для чего и как часто используются снапшоты?

Инкрементальная репликация для бэкапов.

yuripv79
()
Ответ на: комментарий от papin-aziat

Ну…

супруга преподаватель. У неё ~/Documents/Work – сабвольюм, который точно так-же каждый час снепшотится, если были изменения.

И ~/Desktop/HISTORY – ссылочка на снепшоты.

Невелик геморрой, зато есть уверенность в полном спокойствии, если вдруг «файлик исчез, неизвестно, куда».

glebiao
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.