Контролируйте регистры ЦП

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

dd if=/dev/zero of=0.file bs=1024k count=4
losetup /dev/loop0 0.file
pvcreate /dev/loop0
# … repeat for all parts …
vgcreate -s 1m foo /dev/loop0 /dev/loop1 …
lvcreate -l 19 -n big foo
mkfs.btrfs /dev/mapper/foo-big

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

Я не вижу точку: как разделение файлов упрощает резервные копии? Много изменений, вероятно, будут распространены по целому объему (например, несколько частей будут содержать копии суперблока). Вы не получите много, только создавая резервную копию частей, которые изменились: необходимо будет посмотреть далее в частях так или иначе.

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

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

4
30.01.2014, 04:28
3 ответа

Я выполнил следующую команду и не видел изменений также.

$ watch -d "cpuid -r"

Я использовал эту версию:

$ cpuid --version
cpuid version 20130610
0
27.01.2020, 20:54

Команда cpuid не делает то, что вы думаете. См. Статья в Википедии CPUID .

Первый столбец (тот, который в основном считается) - это значение в eax до выполнения инструкции cpuid , остальные столбцы - это значения соответствующих регистров после этого. Следовательно, значения в регистрах представляют ту же информацию об идентификаторе, которую вы получаете при запуске cpuid без -r , и поэтому не изменятся, если вы не измените процессор.

Из Википедии:

EAX = 1:… EBX [биты 31:24]) используется для идентификации выполняющегося логического процессора ».

{{ 1}}

[Если он показывает n различных состояний и у вас n ядер, тогда это будет иметь смысл.]


Примечание : это не ответ о том, как делать то, что вы хотите, а о почему то, что вы делаете, не делает того, что вы хотите. Смотрите мой другой ответ, чтобы узнать, как делать то, что вы хотите.

2
27.01.2020, 20:54

Если вы посмотрите на рабочие регистры на вашем процессоре, то вы правы, они сильно изменятся (очень сильно) .

Если бы вам пришлось написать программу для проверки и сброса содержимого регистров (и это не так уж сложно, если вы знаете C, язык ассемблера для вашего процессора и как их интегрировать (см. Руководство GCC)), тогда вы не увидите, как они меняются (сильно). Хотя они есть. Так почему же это?

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

Как нам разумно смотреть на регистры?

Нам нужна вещь, называемая отладчиком или трассировщиком.

  • Отладчик позволяет вам установить точку останова где-нибудь, что вы хотите проверить. Вы можете установить точки останова в разных местах.

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

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

3
27.01.2020, 20:54

Теги

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