LVM сообщает об ошибках ввода / вывода, но диск сообщает об отсутствии проблем. Argh
Я начал видеть ошибки, сообщаемые LVM на определенных логических томах (и Xen при попытке создать виртуальные машины на этих LV). Но я запустил тесты на диске и не вижу проблем с оборудованием.
Здесь мы используем XEN/Linux (Debian Lenny), используя один диск SATA, управляемый с помощью LVM2. Он работает уже более года, единственными серьезными изменениями являются недавнее обновление ядра apt-get.
# uname -a
Linux hostname 2.6.26-2-xen-amd64 #1 SMP Thu Sep 16 16:32:15 UTC 2010 x86_64 GNU/Linux
Ошибки выглядят так:
# vgck
/dev/dm-20: read failed after 0 of 4096 at 0: Input/output error
И затем, когда я пытаюсь запустить ВМ, которая использует этот LV для своего C-диска (это виртуальная машина Windows), ВМ отказывается запускаться, и я вижу это в конце /var/log/xen/qemu-dm-*.log журнальный файл:
...
Register xen platform.
Done register platform.
raw_read(6:/dev/vgroup/newvm-cdrive, 0, 0x7fff02bca520, 512) [20971520] read failed -1 : 5 = Input/output error
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
raw_read(6:/dev/vgroup/newvm-cdrive, 0, 0x12dfff0, 512) [20971520] read failed -1 : 5 = Input/output error
Это сначала произошло на 2 виртуальных машинах, диск которых был основан на снимке третьей, оригинальной виртуальной машины. Я обстрелял 2 LV и воссоздал их (опять же, сделав снимок того же самого, оригинального LV VM), и с тех пор они были в порядке.
Однако сегодня я попытался создать новую виртуальную машину. Я сделал снимок того же самого, LV оригинальной виртуальной машины (lvcreate -L500M --snapshot --name newvm-cdrive /dev/vgroup/original-cdrive) и создал новую ВМ. Первоначально он работал, но после однократного выключения виртуальной машины он отказывается запускаться снова с ошибками, показанными выше.
Мое очевидное первое предположение - физические проблемы с дисководом, но smartmon ничего не сообщает:
# smartctl -t long /dev/sda
# [later]
# smartctl -l selftest /dev/sda
smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 1 -
# 2 Short offline Completed without error 00% 0 -
Кроме того, не получая ошибок от badblocks,
Я пробовал бегать vgck а также pvck:
# vgck vgroup -v
Using volume group(s) on command line
Finding volume group "vgroup"
/dev/dm-20: read failed after 0 of 4096 at 0: Input/output error
# pvck /dev/sda2
Found label on /dev/sda2, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=192512
Нашли несколько ссылок на это сообщение об ошибке ("Сбой чтения после 0 из 4096 в...") на веб-страницах, но ничего, что, кажется, не применимо к моей ситуации.
Есть идеи?
Обновление: По запросу ниже выводятся команды lvdisplay и ls -l. Выход из космоса COW вполне вероятен. Как мне сказать?
# lvdisplay /dev/vgroup/newvm-cdrive
/dev/dm-20: read failed after 0 of 4096 at 0: Input/output error
--- Logical volume ---
LV Name /dev/vgroup/newvm-cdrive
VG Name vgroup
LV UUID jiarxt-q2NO-SyIf-5FrW-I9iq-mNEQ-iwS4EH
LV Write Access read/write
LV snapshot status INACTIVE destination for /dev/vgroup/original-cdrive
LV Status available
# open 0
LV Size 10.00 GB
Current LE 2560
COW-table size 200.00 MB
COW-table LE 50
Snapshot chunk size 4.00 KB
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:20
# ls -l /dev/dm-20
brw-rw---- 1 root disk 254, 20 2010-10-11 15:02 /dev/dm-20
А вот и фдиск-л.
# fdisk -l /dev/sda
Disk /dev/sda: 160.0 GB, 160000000000 bytes
255 heads, 63 sectors/track, 19452 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000080
Device Boot Start End Blocks Id System
/dev/sda1 * 1 31 248976 83 Linux
/dev/sda2 32 19452 155999182+ 8e Linux LVM
2 ответа
Хорошо, я думаю, что ответ заключается в том, что пространство COW для логического тома заполнено.
Используя команду 'lvs' (которую я только что обнаружил), я вижу...
# lvs
/dev/dm-20: read failed after 0 of 4096 at 0: Input/output error
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
[...other LVs...]
newvm-cdrive mrburns Swi-I- 2.00G original-cdrive 100.00
[...other LVs...]
Эта заглавная буква "S" в начале столбца "Attr" означает "недопустимый снимок". (Нижний регистр 's' будет означать (действительный) снимок.) И, как вы можете видеть, Snap% равен 100, т. Е. Он использует все свое пространство COW.
Досадно, lvdisplay не предоставляет эту информацию и не сообщает вам, что ваш логический том моментального снимка недействителен. (Все, что он говорит, - то, что состояние снимка является "НЕАКТИВНЫМ", которое я принял как значение "не используется в настоящее время".) lvs Команда не очень широко рекламируется. И сообщение об ошибке ("Ошибка ввода / вывода") не очень полезно - на самом деле не было никаких сообщений журнала или сообщений об ошибках, которые предлагали бы "снимок заполнен". (Более поздние версии LVM2 записывают сообщения в /var/log/messages, когда пространство начинает заполняться, но версия в Debian Lenny этого не делает. Boo.)
И, чтобы усугубить проблему, в Интернете нет обсуждения этого (или, по крайней мере, не то, что я мог найти)!
Мне было интересно, почему снимки COW нельзя исправить, просто добавив больше места в LV (используя lvextend, но на самом деле пространство COW потребуется не только при записи в место назначения снимка, но и при записи в источник снимка. Поэтому, как только ваша область COW будет заполнена, любые записи в исходный LV должны обязательно сделать снимок LV недействительным, и его нелегко восстановить.
(Не прямой ответ, но я надеюсь использовать его для других, которые борются за 100% полных снимков, которые вызывают ошибки ввода / вывода)
Это случилось со мной: мой моментальный снимок заполнился на 100%, но файловая система в нем думала, что у него много места, что привело к input/output ошибки всякий раз, когда я бежал lvs или любая другая команда LVM2.
В моем случае единственный вариант - удалить снимок с lvremove, но я не мог, потому что я лениво размонтировал снимок с помощью umount -l, Это сделало очень трудным отследить, какие процессы использовали недавно смонтированную файловую систему.
Я нашел успех, получив основные + второстепенные номера устройств логического тома, например 252:10 В следующих:
root@hostname:~# lvdisplay
--- Logical volume ---
LV Path /dev/vg00/
LV Name snapshot_of_my_origin
VG Name vg00
LV UUID CWZxOa-depw-k5P4-SqDo-bdFb-h3Np-ukQkmM
LV Write Access read/write
LV Creation host, time cz3328jlkj, 2016-07-12 13:47:31 +0100
LV snapshot status active destination for my_origin
LV Status available
# open 1
LV Size 150.00 GiB
Current LE 38400
COW-table size 50.00 GiB
COW-table LE 12800
Allocated to snapshot 0.03%
Snapshot chunk size 4.00 KiB
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:10
Если вы бежите lsof В качестве пользователя root без аргументов вы получите полный список открытых файлов в системе. Выполните фильтрацию по номерам основных и второстепенных блочных устройств, разделенных запятой, а не двоеточием, как указано выше, и вы можете найти процесс, используя его:
root@hostname:~# lsof | sed -ne '1p; / 252,10 /p'
COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 2055 upr473 cwd DIR 252,10 4096 2 /
Обратите внимание, что NAME является /потому что он был лениво размонтирован, lsof не может разрешить свое первоначальное имя пути.
Убить этот процесс, 2055 в этом примере и попробуйте lvremove и снова