Там есть разница в подходе к записи данных. В случае записи в файл под LVM snapshot физическая запись выполняется в тоже самое физическое место (т.е. как будто это обычная запись) и одновременно с этим выполняется копирование предыдущего состояния данных в новое место.
Если проще — то во время записи создаётся бэкап старой записи и кладётся в отдельно место. Т.е. выполняется две операции записи, поэтому это медленнее.
Так сделано, потому что LVM snapshot универсальная прослойка для любой ФС, а сделать по другому без знания внутренностей ФС не получиться.
> Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Ничего плохого, я лишь указываю, что это не основная цель этой технологии и что с основными целями COW в Linux отлично справляется. Главная задача COW быть небольших базовым кирпичиком который позволяет реализовывать в том числе и дедупликацию, но именно реализовывать там где это нужно (вот в docker например), а не предоставлять это по-умолчанию.
В docker, кстати, дедупликация реализуется вовсе не через cp с ключиком, а явно через снимки файловой системы (что супер быстро, в отличии от cp).
> А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Верно. И я указываю на то, что COW позволяет сильно проще (насколько проще, что это прям оправдывает создание этой технологии только для этого) и надежнее реализовывать механизмы обеспечения целостности в ФС.
Тут проблема не в COW механизме для Linux, а с изначально неправильными ожиданиями и пониманием технологии COW у автора.
Вы серьезно думаете, что COW был придуман, чтобы позволить быстро копировать файлы? Это вообще не так. И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Основное назначение COW это предоставить механизм который позволяет при записи в тот же самый фал не перезаписывать байтики по тому же физическому месту, а записывать их в отдельное физическое место. И этот базовый механизм нужен, чтобы быть основой для следующих возможностей:
1. легкость восстановления предыдущего состояния файла (через механизм снимков или вручную)
И «легкость» тут как и для пользователя, так и техническая для разработчиков. Потому, что без COW есть другой механизм снимков — LVM snapshots — но его главная проблема это производительность и эта проблема как раз возникает потому без COW сделать механизм снимков эффективным не получится.
Замечали что для всех ФС у которых есть COW, так же есть и поддержка снимков, а где нет COW, то и снимки приходиться делать через «недешевый» LVM snapshots. Совпадение?
2. восстановления целостности файла при сбое (по питанию)
Тут опять же, COW просто сильно упрощает (для разработчиков) и делает более надежным механизмы восстановления файловой системы.
— То, что COW может ускорить копирования — просто побочная случайность, а не фича технологии. Поэтому с COW в Linux все ОК — оно работает ровно так как и задумывалось.
Когда популярность приложения разрастется и следовательно начнет сильно расти трафик и количество запросов, то в качестве хостинга файлов хорошо подойдет облачное хранилище от selectel.
Давно использую salt (чуть ли ни с его рождения), мне очень нравятся те идеи которые в нем заложены, простота и невероятная гибкость. Тем не менее есть и негатив от него. Сразу списком, а ниже подробнее:
1) нестабильность версий и плохое их тестирование;
2) часто ломают совместимость;
3) ужасный стиль кода и плохая внутренняя согласованность.
У меня написано весьма немало конфигураций, в том числе достаточно сложные и взаимосвязанных, и чуть-ли ни каждая новая версия salt ломала ранее работавшие конфигурации. Приходилось экстренно либо находить/придумывать воркэраунды либо исправлять код самому. И вот новый переход на последнею версию опять сломал кое-что (уже сам пофиксил и заслал автору pull request).
Так же несколько раз случалось, что новые версии minion'ов требовали также обновленного master'а, то есть нельзя было компоненты salt обновлять постепенно, а нужно было только сразу везде и до одинаковой версии. Для продакта это так же «неприятно».
Поскольку мне приходилось и самому писать какие-то модули для него и исправлять что-то внутри, то у меня есть представление о том как он написал с точки зрения программиста. Так вот, писал его явно не программист. Прям по коду видно как автор все больше и больше узнавал как же писать на python и старался писать все более правильнее со временем. От одних только __getitem___ по всему коду плакать хочется. Ну и целом очень много решений «в лоб» без обобщений. Прям иногда есть желание форкнуть и вычистить все, сдерживаюсь пока :-)
Кстати, действительно невероятная гибкость salt тоже иногда играет ему в минус, потому что одну и туже конфигурацию можно написать тучей способов и, когда нет опыты, сложно выбрать как именно. Возможно, ваши статьи помогут начинающим сориентироваться как это все готовить.
Так что, если вы думаете выбрать salt для продакта, то учтите есть ли у вас навыки и желание, что-то в нем исправлять и обслуживать как отдельную сущность (следить за обновлениями). Конечно, проект развивает (и очень быстро), поэтому есть вера, что будет становиться все лучше и лучше.
При привязке домена записи проверяются на NS'ах самого домена, поэтому изменения видим быстро. Соглашусь, возможен некоторый провал, но если действовать оперативно, посетители сайта этого не заметят.
Почему ж гарантирован? Никто не мешает перенести нужные данные в Хранилище, выполнить изменения в ДНС и привязку домена и при этом не отключать старый сервер. Все новые запросы будет обрабатывать Хранилище, а тем кому «не повезло» некоторое время будут на старом сервере. Дальше старый сервер отключаем (по прошествую TTL ДНС с запасом). Никакого даунтайма.
А для боевого кода уже давно есть wrapt — всё уже реализовано и к тому же ультра быстро (да иногда скорость применения декораторов имеет значение).
Если проще — то во время записи создаётся бэкап старой записи и кладётся в отдельно место. Т.е. выполняется две операции записи, поэтому это медленнее.
Так сделано, потому что LVM snapshot универсальная прослойка для любой ФС, а сделать по другому без знания внутренностей ФС не получиться.
Ничего плохого, я лишь указываю, что это не основная цель этой технологии и что с основными целями COW в Linux отлично справляется. Главная задача COW быть небольших базовым кирпичиком который позволяет реализовывать в том числе и дедупликацию, но именно реализовывать там где это нужно (вот в docker например), а не предоставлять это по-умолчанию.
В docker, кстати, дедупликация реализуется вовсе не через cp с ключиком, а явно через снимки файловой системы (что супер быстро, в отличии от cp).
> А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Верно. И я указываю на то, что COW позволяет сильно проще (насколько проще, что это прям оправдывает создание этой технологии только для этого) и надежнее реализовывать механизмы обеспечения целостности в ФС.
Вы серьезно думаете, что COW был придуман, чтобы позволить быстро копировать файлы? Это вообще не так. И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Основное назначение COW это предоставить механизм который позволяет при записи в тот же самый фал не перезаписывать байтики по тому же физическому месту, а записывать их в отдельное физическое место. И этот базовый механизм нужен, чтобы быть основой для следующих возможностей:
1. легкость восстановления предыдущего состояния файла (через механизм снимков или вручную)
И «легкость» тут как и для пользователя, так и техническая для разработчиков. Потому, что без COW есть другой механизм снимков — LVM snapshots — но его главная проблема это производительность и эта проблема как раз возникает потому без COW сделать механизм снимков эффективным не получится.
Замечали что для всех ФС у которых есть COW, так же есть и поддержка снимков, а где нет COW, то и снимки приходиться делать через «недешевый» LVM snapshots. Совпадение?
2. восстановления целостности файла при сбое (по питанию)
Тут опять же, COW просто сильно упрощает (для разработчиков) и делает более надежным механизмы восстановления файловой системы.
— То, что COW может ускорить копирования — просто побочная случайность, а не фича технологии. Поэтому с COW в Linux все ОК — оно работает ровно так как и задумывалось.
PS: как раз akme иллюстрирует
Ну серьезно, куда уж три то равно… понимаю еще два, но три…
1) нестабильность версий и плохое их тестирование;
2) часто ломают совместимость;
3) ужасный стиль кода и плохая внутренняя согласованность.
У меня написано весьма немало конфигураций, в том числе достаточно сложные и взаимосвязанных, и чуть-ли ни каждая новая версия salt ломала ранее работавшие конфигурации. Приходилось экстренно либо находить/придумывать воркэраунды либо исправлять код самому. И вот новый переход на последнею версию опять сломал кое-что (уже сам пофиксил и заслал автору pull request).
Так же несколько раз случалось, что новые версии minion'ов требовали также обновленного master'а, то есть нельзя было компоненты salt обновлять постепенно, а нужно было только сразу везде и до одинаковой версии. Для продакта это так же «неприятно».
Поскольку мне приходилось и самому писать какие-то модули для него и исправлять что-то внутри, то у меня есть представление о том как он написал с точки зрения программиста. Так вот, писал его явно не программист. Прям по коду видно как автор все больше и больше узнавал как же писать на python и старался писать все более правильнее со временем. От одних только __getitem___ по всему коду плакать хочется. Ну и целом очень много решений «в лоб» без обобщений. Прям иногда есть желание форкнуть и вычистить все, сдерживаюсь пока :-)
Кстати, действительно невероятная гибкость salt тоже иногда играет ему в минус, потому что одну и туже конфигурацию можно написать тучей способов и, когда нет опыты, сложно выбрать как именно. Возможно, ваши статьи помогут начинающим сориентироваться как это все готовить.
Так что, если вы думаете выбрать salt для продакта, то учтите есть ли у вас навыки и желание, что-то в нем исправлять и обслуживать как отдельную сущность (следить за обновлениями). Конечно, проект развивает (и очень быстро), поэтому есть вера, что будет становиться все лучше и лучше.