Это довольно распространенная проблема, когда в SAN for ext3 что-то идет не так, чтобы обнаружить ошибки записи на диск и перемонтировать файловую систему только для чтения. Это все хорошо, только когда SAN исправлен, я не могу понять, как перемонтировать файловую систему для чтения-записи без перезагрузки.
Вот:
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdb 8:16 [active][ready]
\_ 2:0:0:1 sdc 8:32 [active][ready]
[root@localhost ~]# mount /dev/mapper/mpath0 /mnt/foo
[root@localhost ~]# touch /mnt/foo/blah
Все хорошо, теперь я вытаскиваю LUN из-под него.
[root@localhost ~]# touch /mnt/foo/blah
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
[root@localhost ~]# tail /var/log/messages
Mar 18 13:17:33 localhost multipathd: sdb: tur checker reports path is down
Mar 18 13:17:34 localhost multipathd: sdc: tur checker reports path is down
Mar 18 13:17:35 localhost kernel: Aborting journal on device dm-2.
Mar 18 13:17:35 localhost kernel: Buffer I/O error on device dm-2, logical block 1545
Mar 18 13:17:35 localhost kernel: lost page write due to I/O error on dm-2
Mar 18 13:17:36 localhost kernel: ext3_abort called.
Mar 18 13:17:36 localhost kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal
Mar 18 13:17:36 localhost kernel: Remounting filesystem read-only
Он думает только о том, что доступен только для чтения, в действительности его даже нет.
[root@localhost ~]# multipath -ll
sdb: checker msg is "tur checker reports path is down"
sdc: checker msg is "tur checker reports path is down"
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16 [failed][faulty]
\_ 2:0:0:1 sdc 8:32 [failed][faulty]
[root@localhost ~]# ll /mnt/foo/
ls: reading directory /mnt/foo/: Input/output error
total 20
-rw-r--r-- 1 root root 0 Mar 18 13:11 bar
Как он по-прежнему помнит, что файл 'bar' находится там ... загадка, но сейчас это не важно. Теперь я представляю LUN:
[root@localhost ~]# tail /var/log/messages
Mar 18 13:23:58 localhost multipathd: sdb: tur checker reports path is up
Mar 18 13:23:58 localhost multipathd: 8:16: reinstated
Mar 18 13:23:58 localhost multipathd: mpath0: queue_if_no_path enabled
Mar 18 13:23:58 localhost multipathd: mpath0: Recovered to normal mode
Mar 18 13:23:58 localhost multipathd: mpath0: remaining active paths: 1
Mar 18 13:23:58 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:58 localhost multipathd: dm-2: devmap already registered
Mar 18 13:23:59 localhost multipathd: sdc: tur checker reports path is up
Mar 18 13:23:59 localhost multipathd: 8:32: reinstated
Mar 18 13:23:59 localhost multipathd: mpath0: remaining active paths: 2
Mar 18 13:23:59 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:59 localhost multipathd: dm-2: devmap already registered
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][enabled]
\_ 1:0:0:1 sdb 8:16 [active][ready]
\_ 2:0:0:1 sdc 8:32 [active][ready]
Отлично верно? Там написано [rw]. Не так быстро:
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
ОК, не делайте этого автоматически, я просто немного подтолкну:
[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only
Черт возьми, вы
[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only
Noooooooooo.
Я перепробовал все виды различных команд mount / tune2fs / dmsetup, и я не могу понять, как заставить его отключить блокировку устройства как защищенного от записи. Перезагрузка это исправит, но я бы предпочел сделать это онлайн. Час поиска в Google тоже ни к чему не привел. Спаси меня ServerFault.
3
хм, пара вопросов «Это довольно распространенная проблема, когда что-то не так в сети SAN», почему ваша сеть SAN настолько ненадежна, я бы сначала проверил это? Вы пробовали просто размонтировать с помощью umount, а затем снова смонтировать? Есть ли веская причина, почему вам нужно сделать пересчет? Мне обычно нужно только перемонтировать мои корневые файловые системы после техобслуживания.
—
Дворник Unix
размонтировать отскоки на дескрипторах открытых файлов, которые часто происходят из процессов, которые вы бы предпочли без труда завершить.
—
cagenut
У меня есть похожая проблема, когда после проблемы SAN диски виртуальных машин только для чтения, и попытка перемонтировать вызывает ту же ошибку в OP. Виртуальные машины находятся на esxi 4.1 с хранилищем Fibre Channel. Перезагрузка виртуальной машины устраняет проблему. Я лично не думаю, что это связано с многолучевым распространением. Конечно, должен быть способ исправить без перезагрузки, тем более что некоторые службы (apache), как правило, продолжают работать на FS только для чтения.
—
Будет
Я пришел сюда в поисках решения моей собственной проблемы (которая отличается от поврежденного диска). Я улыбнулся вместо этого. +1 за "черт возьми"
—
user1207217
У меня точно такая же проблема, как эта, но я использую LVM. Тот же lvdisplay выдаст мне «ошибка чтения после 0 из 4096 при 449197309952: Ошибка ввода-вывода», пока я не выполнил «multipath -r», затем LVM начал отображать все правильно без ошибок. Однако я до сих пор не могу перемонтировать раздел. Не может также размонтировать, говорит, что устройство занято. Если я выключаю все процессы, используя устройство, я могу размонтировать, а затем успешно перемонтировать, но я бы предпочел просто перемонтировать устройство для чтения-записи, как я должен быть в состоянии ...
—
mpontes