☰

Стоит ли мне беспокоиться? В системном журнале сообщается о сбоях сегментации при слиянии моментального снимка LVM (возврате оригинала к моментальному снимку)

tag-icon • tag-icon linux lvm segmentation-fault snapshot
Стоит ли мне беспокоиться? В системном журнале сообщается о сбоях сегментации при слиянии моментального снимка LVM (возврате оригинала к моментальному снимку)

Я просто экспериментировал со снимками в LVM на Ubuntu 12.10. Я создал логический том снимка размером 6,5 ГиБ и, внеся некоторые изменения в источник, решил снова объединить снимок, чтобы отменить их. Все, казалось, шло хорошо, но я заметил несколько сообщений об ошибках сегментации, связанных с LVM, в системном журнале.

Введенные команды:

sudo lvcreate -L6.5G -n backup_snapshot -s /dev/mapper/vg0-backup
# made some miscellaneous writes
sudo lvconvert --merge /dev/vg0/backup_snapshot
sudo umount /snapshot/backup
sudo umount /backup
sudo lvchange -an /dev/vg0/backup
sudo lvchange -ay /dev/vg0/backup
sudo mount /backup

Из системного журнала:

Apr 12 04:57:10 bournemouth kernel: [ 5260.813253] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:00:11 bournemouth kernel: [ 5441.841401] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:02:00 bournemouth kernel: [ 5551.438487] show_signal_msg: 48 callbacks suppressed
Apr 12 05:02:00 bournemouth kernel: [ 5551.438495] lvm[5813]: segfault at 28 ip 000000000047f319 sp 00007fff60873de0 error 4 in lvm[400000+d9000]
Apr 12 05:02:01 bournemouth kernel: [ 5552.458797] lvchange[6449]: segfault at 28 ip 000000000047f319 sp 00007fff935f4380 error 4 in lvm[400000+d9000]

Затем я размонтировал исходный LV, убедился, что моментального снимка больше не существует, и запустил fsck.ext4 -fего; таким образом проверка прошла успешно. Но я все еще беспокоюсь о сегментациях. Возможно ли, что мои данные были испорчены каким-то образом, который fsck не выявит? Том, с которым я экспериментировал, был резервным, и все файловые системы, которые я на нем скопировал, все еще в рабочем состоянии, поэтому я мог бы просто начать все сначала и снова их скопировать. Но с другой стороны, я хотел бы сохранить свою историю инкрементного резервного копирования. Я просто хотел бы быть уверенным, что могу доверять этим резервным копиям.

решение1

Да, это определенно ошибка, но не волнуйтесь, LVM достаточно умен, чтобы справиться с этим. Однажды у меня отключилось электричество прямо во время pvmove, и все, что мне пришлось сделать, это снова включить сервер, «отменить» старый pvmove и запустить его заново.

Во-первых, важно знать, что используемые вами инструменты — это всего лишь интерфейс пользовательского пространства к процессам ядра. LVM находится внутри ядра, так что если только ваше ядро ​​не паникует, то все в порядке. Инструменты пользовательского пространства, такие как pvmove или lvchange, просто взаимодействуют с LVM для нас, а затем просто откидываются назад и спрашивают ядро: «Эй, ты уже закончил с этим? Как все получилось?» или «Эй, как далеко мы продвинулись с этим?» (Ваша конкретная проблема — это ошибка сегментации lvchange после успешного завершения lvchange,похоже на недавно исправленную ошибкупоэтому вам, возможно, захочется убедиться, что у вас установлены все обновления системы).

В целом, вам также не следует быть таким беспокойным или параноидальным по поводу того, есть ли у вас проблемы с LVM, он разработан для обработки таких неожиданных ошибок (даже если они влияют на него напрямую, а не только на используемый вами инструмент), и эта гарантия является частью смысла использования менеджера томов вместо традиционных разделов. У вас будут проблемы только если что-тоДействительноплохое случается или вы делаете что-то не обдумав. LVM работает по экстентам (вместо блоков) и не делает скопированный экстент активным, а исходный неактивным, пока операция копирования не будет успешно завершена. При этом наполовину скопированные экстенты останутся помеченными как нераспределенные, и любые последующие инструменты просто перезапишут их. Так обстоит дело с моим pvmove и вашим lvchange.

РЕДАКТИРОВАТЬ:

Смотря наэто объявление в списке рассылки, мы можем получить более подробное описание того, как на самом деле работает ваше слияние «под капотом»:

Пока слияние активно, все обращения к исходному устройству [направляются] на снимок, который объединяется. Когда слияние завершается, исходный целевой объект плавно перезагружается, а снимок слияния удаляется. Файловая система [не-снимка] может оставаться смонтированной в это время.

Подумал, что будет интересно узнать

решение2

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

Если инструмент LVM даст сбой сегментации в процессе обновления таких метаданных, возможна потеря данных. В некотором смысле LVM — это файловая система для разделов; поврежденные метаданные LVM будут эквивалентны потере суперблока файловой системы. Вот почему почти каждое изменение регистрируется/резервируется в /etc/lvm/....

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

Связанный контент