ZFS и снапшоты. Вопрос 1,2,3

[EsTaF]

Вопросы толстые и в чем-то наглые. Много невежества в них, но как не диагонально не искал ответы, встречал либо копипасты в блогах по zfs про распрекрасность, либо голый академизм в мануалах. Отчасти - это из-за лени. Но не было бы лени, не было бы и форумов.
Появился у человека, пусть и маленький вопрос, он взял, обложился литературой на месяц и как начал сначала все читать и перечитывать талмудами, да и нашел ответ. Может так и правильно, но вот я взял и пошел вот таким путем - задал эти вопросы здесь. Кто-то осудит - его право. А кто-то может и ответит.

1. Давно был такой вопрос, как создание снимка фс, если на нее копируется какой-либо файл.
Пример.
В задачах создаем действие - делать снимки определенного датасета раз в час, каждый день.
Все хорошо. Снимки делаются. Иногда мы вытаскиваем нужные файлы из клонов.
В один прекрасный момент на датасет копируется файл видео извне. Копируется он с 3 минуты. Условно, 22 июля, 18 года. В 12 часов, шесть минут он начал копироваться, а в 9 минут копирование было закончено.
В этот момент, в таскс частота создания снимков попала на зоздание снимка на 12 часов 8 минут. Был создан снимок в момент, когда было скопировано лишь процентов 70 файла.
Я знаю, что вопрос тупейший. Ну увидел я, что файл не алло, взяв другой экземпляр снимка фс, который был сделан через час. Но пример с видео чисто условный. Могут быть ситуации, которые сразу в голову и не придут, а в жизни с ними столкнуться можно очень даже. Натолкнуться на факт битого видео еще как-то можно, но ведь могут быть так восстановленные фвйлы, которые сразу и не проверишь, как видео.

Собственно, вопрос не в том, как быть, а про поведение системы. Как она делает снимок. Дожидается ли завершения записи данных и только потом делает снимок, или же делает снимок, вне зависимости от событий. Плохо, или хорошо - вопрос десятый. Сам факт.
Кто об этом что-нибудь знает?

########
2. Возможно ли искать файлы внутри снимков, не создавая клон для каждого? Если да, то как?

########
3. Существует ли механизм удаления выбранных пользователем файлов в снимках?

 

[mav@]

1. Вся работа ZFS построена на транзакциях. Когда код файловой системы ZFS хочет внести какое-то изменение, он открывает транзакцию, делает свои грязные дела и закрывает транзакцию. Эти транзакии по определению атомарны. Но так как размер транзакции ограничен максимум где-то 16МБ, а зачастую много меньше -- одним сисколом, что может быть и записью одного байта и переименованием файла, то обрабатывать каждую отдельно слишком дорого. По этому транзакции объединяются в группы, известные как txg. В момент открытия каждая транзакция попадает в какую-то группу. Когда набирается некая критическая масса или истекает таймаут, группа транзакций закрывается и коммитится на диск. Есть механизм, позволяющий выполнить коммит в любой момент по желанию, однако обратного механизма растянуть группу транзакций не существует. Таким образом, если пользователь потребует пообещать что некий записанный файл сохранен надежно и полностью, ZFS это легко обеспечит, но вот в промежутке между этими запросами она вольна себя вести так как ей удобнее -- каждая отдельная тразакция будет атомарна и порядок их будет сохранен, но какие из них уже закоммичены, а какие только будут -- не уточняется. Создание снапшота, как и любые другие административные манипуляции с пулом или датасетами всегда коммитят группу транзакций, что попутно гарантирует что все транзакции открытые до этого момента входят в нужную группу и станут частью этого снапшота. Те же что открыты еще не были -- пойдут уже в следующий. Отсюда и выходит что снапшот созданный посреди записи файла будет содержать обрезок. Как вариант обеспечения атомарности -- писать файл под временным именем, а потом переименовывать, так как переименованием атомарно.

2. Каждый dataset имеет скрытый каталог .zfs/snapshots , отображающий снапшоты как подкаталоги, в которые при обращении в read-only автоматически монтируется содержимое снапшота.

3. А вот этого не бывает. Снимки на диске неизменны. Единственно в разработке находится фича redacted send/receive, которая позволяет модифицировать снапшоты во время репликации.

 

[EsTaF]

Исчерпывающе. Премного благодарен за столь не двусмысленное и подробное описание.

По первому пункту, в принципе, вообще нет проблем. При восстановлении всегда можно взять файл из первого+1(или два)! снимка.
Второй пункт (поиск) очень даже хорошо, что так можно.
А вот по третьему да, пролет. Если в снимках находится файл, который больше никогда не пригодится и имеет очень большой вес, то придется либо смириться, либо удалять все снимки, время которых равно жизни такого файла. Но, если мы точно не уверены, что в этих снимках могут быть и еще какие-то файлы, которые были удалены случайно нами и мы не помним, какие, то придется оставить их. Еще одним вариантом удаления оных - это если сделать синхронизацию с ключем теста (эмуляция в rsync). Посмотреть разность. Оценить разность. Сохранить нужные прошлые удаленные файлы, которые нужны нам, а затем удалить снимки с такими ненужными большими файлами. Но - это если файлов очень много и они весят на диске, приближаясь к процентам 70 от всего диска, наверное.

2mav@
Мое вам уважение и большое спасибо за ответ.