Я хотел бы использовать BTRFS для размещения виртуальных машин в VirtualBox, чтобы иметь возможность использовать моментальные снимки без LVM или чего-то подобного. Теоретически мне не нужно постоянно поведение CoW из-за соображений производительности и использования nodatacow мне кажется, что мне это не нужно. Вместо этого я хотел бы использовать подход, основанный на моем понимании: Windows и NTFS, похоже, используют: данные постоянно изменяются без CoW , но если создается моментальный снимок файловой системы, текущие данные сохраняются в этом снимке путем копирования данных. прочь, если это нужно изменить каким-либо образом. Важным представляется то, что это происходит только один раз для каждого снимка и действительно только для модифицированных блоков. Таким образом, после того, как подлежащий изменению блок был сначала скопирован, все последующие модификации к тому же блоку просто применяются, опять же без поведения CoW .

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

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

Из моего понимания документов BTRFS, если CoW случается один раз с каким-то файлом, это происходит всегда. Но я могу ошибаться, конечно ...

Итак, что я хотел бы иметь вообще возможно с BTRFS?

1 ответ1

1

Если CoW случается один раз с каким-то файлом, это происходит вечно. Но я могу ошибаться, конечно.

Я думаю, что вы не правы. Я нашел этот вопрос о создании снимков тома BTRFS, смонтированного с помощью nodatacow. Там есть цитата (из списка рассылки BTRFS), которая кажется решающей для вашего случая:

В файле NOCOW первая запись в файловый блок (4096 байт) после моментального снимка должна все еще быть COW, потому что моментальный снимок блокирует старую версию на месте, и теперь файловый блок изменился, поэтому он ДОЛЖЕН быть записан в другом месте, несмотря на упорядоченный NOCOW чтобы сохранить снимок, как это было. Тем не менее, файл сохраняет атрибут NOCOW, и дополнительные записи в тот же файловый блок будут на месте ... до следующего снимка, конечно.

Похоже, опция монтирования nodatacow дает именно то, что вы хотите. Просто помните, что есть ограничения:

nodatacow
Не копируйте данные при записи для вновь созданных файлов, существующие файлы не затрагиваются. Это также отключает контрольную сумму! […] Возможно получение частично обновленных файлов при сбоях системы. […] Отключает сжатие!

Источник: параметры монтирования BTRFS.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .