Я начал видеть ошибки, сообщаемые 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 LV и воссоздал их (опять же, сделав снимок того же самого LV LV), и с тех пор они в порядке.
Однако сегодня я попытался создать новую виртуальную машину. Я сделал снимок того же исходного 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. Вполне вероятно, что не хватит места для коровы. Как мне сказать?
# 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.
# 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
Хорошо, я думаю, ответ состоит в том, что пространство 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 и др. снова.