Я должен беспокоиться? Segfaults сообщается в syslog при объединении моментального снимка LVM (возврат оригинала обратно к снимку)

Я просто экспериментировал со снимками в LVM на Ubuntu 12.10. Я создал логический том моментального снимка 6.5 GiB, и после внесения некоторых изменений в начало координат решил объединить снимок, чтобы отменить их. Кажется, все идет хорошо, но я заметил несколько сообщений о segfault, связанных с LVM, в syslog.

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

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 

Из syslog:

 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 ; таким образом. Но я все еще беспокоюсь о segfaults. Возможно ли, что мои данные были испорчены каким-то образом, что fsck не поймает? Том, с которым я экспериментировал, был резервным, и все файловые системы, которые я поддерживал на нем, все еще находятся в рабочем состоянии, поэтому я мог просто начать все заново. Но, с другой стороны, я хотел бы сохранить историю инкрементного резервного копирования. Я просто хотел бы подтвердить, что могу доверять этим резервным копиям.

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

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

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

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

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

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

Возможно, было бы интересно узнать

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

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

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