Снимок LVM без копии на записи

Если Вы уверены, что нет никаких новых строк в Ваших именах файлов, не преобразовывают пустые байты в новые строки и вызов head сохранить только первые несколько строк.

<abc.txt tr '\0' '\n' |
head -n 50 |
tar --null --no-recursion -uf abc.tar --directory= /tmp/temp --files-from -

Для преодоления имен файлов, содержащих новые строки, Вы можете транспонировать новые строки и аннулируете, затем позвольте head к его материалу, и транспонируют назад.

<abc.txt tr '\0\n' '\n\0' |
head -n 50 |
tr '\0\n' '\n\0' |
tar --null --no-recursion -uf abc.tar --directory= /tmp/temp --files-from -
3
11.03.2014, 08:17
2 ответа
[112492]Стоимость снимка не может быть нулевым байтом. Когда блок изменяется в исходном томе, и у вас есть снэпшот, необходимо сделать копию исходного блока до модификации - исходные данные должны быть доступны [112982]каким-то образом[112983], чтобы они были доступны из снэпшота.[12195]Это и есть размер снэпшота (плюс некоторые метаданные): оригинальные копии блоков, которые с тех пор были изменены в исходном тексте.[12196]Обратите внимание, что это может быть "уловкой учета": Реализация может выбрать не перезаписывать исходный блок на диск, а хранить новые данные где-нибудь в другом месте и обновлять список исходных блоков (или что-то еще, что используется для отслеживания). В этом случае снэпшот является "статическим" по вашему определению. Но это все равно приводит к росту общего количества выделенных блоков всякий раз, когда блок исходного текста модифицируется. Это использование пространства должно (a) учитываться в снимке.[12197]Это справедливо как для RO, так и для RW снимков, за исключением того, что это немного сложнее в случае RW (вы не хотите перезаписывать блок, который был модифицирован в снимке оригинальным блоком из исходного текста, если он тоже модифицирован, например)[112499].
5
27.01.2020, 21:16

Я только что изучил эту тему, как и в OP, основной момент путаницы связан с «мышлением в файлах», в то время как LVM работает с физическими экстентами .

Обычно LVM располагается между жестким диском и файловой системой, каждый из этих трех слоев имеет свой термин для понятия «одинакового размера фрагменты байтов»:

hdd: sectors (512 bytes) -> LVM: physical extents (4MB) -> file system: blocks (e.g. 4K)

Я создал большое кольцевое устройство размером 200 МБ, 100 МБ для логического тома (testlv )и 60 МБ для моментального снимка LV (snaplv ).

LV 100 МБ можно представить как состоящий из 25 физических экстентов, каждый из которых представляет блоки файловой системы размером 4 МБ. Снапшот LV изначально также ссылается на эти PE, на данный момент он не использует свои 15 PE. Всякий раз, когда пользователь выполняет запись в файловую систему любого логического тома, файловая система изменяет содержимое одного или нескольких блоков , которые, конечно же, сами хранятся в физических экстентах LVM.

Таким образом, изменение PE из testlv означает:

  1. скопировать содержимое PE в один из запасных PE snaplv(скопировать -на -записать)
  2. изменить ссылку snaplv на этот "новый" PE
  3. обновить содержимое "исходного" тестового PE

Очевидно, что изменение PE из snaplv почти не отличается, только последний шаг отличается тем, что будет обновлена ​​копия PE snaplv.

0
27.01.2020, 21:16

Теги

Похожие вопросы