LVM сообщает об ошибках ввода-вывода, но диск не сообщает ни о каких проблемах. Argh
RSA делают официальные программные токены для некоторых КПК. Наша компания устанавливает версию программного обеспечения маркера на корпоративных Blackberry, для сохранения пользователей, имеющих необходимость нести вокруг аппаратного ключа, а также их BB.
Наличие программного обеспечения на КПК сохраняет аспект с двумя факторами безопасности (что-то, что Вы имеете и что-то, что Вы знаете), способом, что установка программного токена на том же настольном ПК, от которого Вы, вероятно, соединяетесь с ресурсом, не делает.
Также использование официального программного токена RSA, как распределено Вам людьми, управляющими доступом к ресурсу, очень, намного лучшая идея, чем использование некоторых взломанных о бите программного обеспечения, которое, вероятно, повреждает все виды соглашений между Вами, выпускающим и RSA.
Посмотрите здесь для официальных программных аутентификаторов RSA, обратите внимание, что, хотя можно просто загрузить некоторых из тех, которые не испытывают никаких затруднений, они не будут работать без записи ключа/семени, выпущенной людьми, которые выполняют ресурс, к которому Вы пытаетесь получить доступ.
Хорошо, я думаю, что ответ - то, что пространство 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' означает 'недопустимый Снимок'. (Нижний регистр' означал бы (допустимый) снимок.) И как Вы видите, Поспешный % равняется 100, т.е. это использовало все свое пространство COW.
Раздражающе, lvdisplay не предоставляет эту информацию, и она не говорит Вам, что Ваш логический том снимка недопустим. (Все, что это говорит, - то, что состояние снимка 'НЕАКТИВНО', который я взял в качестве значения 'не использующийся в настоящее время'.) И lvs команда очень широко не рекламируется. И сообщение об ошибке ("ошибка ввода/вывода") не очень полезно - на самом деле не было никаких сообщений журнала или сообщений об ошибках, которые предположили, что 'снимок полон'. (Позже версии LVM2 пишут сообщения в/var/log/messages, когда пространство начинает заполняться, но версия в Debian Lenny не делает. Шиканье.)
И усугублять проблему, нет никакого обсуждения этого в Интернете (или по крайней мере, не, что я мог найти)!
Я задавался вопросом, почему снимки COW не могут быть починены, просто добавив больше пространства к LV (использование lvextend, но на самом деле пространство COW будет требоваться, не только когда Вы пишете в место назначения снимка, но также и когда Вы пишете в источник снимка. Таким образом, после того как Ваша область COW заполнена, любые записи к источнику, LV должен обязательно сделать снимок LV недопустимый, и не легко восстанавливаемый.
(Не прямой ответ,но я надеюсь, что это поможет другим, борющимся со 100% полными снимками, которые вызывают ошибки ввода / вывода)
Это случилось со мной: мой снимок стал на 100% заполнен, но файловая система в нем думала, что у него много места, в результате ошибки ввода / вывода всякий раз, когда я запускал 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 /
Обратите внимание, что ИМЯ / , поскольку он был отложен отмонтирован, lsof не может разрешить его исходное имя пути.
Завершите этот процесс, 2055 в этом примере, и попробуйте lvremove и др.