Как перемонтировать ext3 fs readwrite после монтирования readonly из-за ошибки диска?

18

Это довольно распространенная проблема, когда в 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.

centos mount ext3 read-only cagenut
источник
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

Ответы:

6

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

echo running > /sys/block/device-name/device/state

Я думаю, что вы, возможно, захотите взглянуть на раздел 25.14.4: Изменение состояния чтения / записи логического модуля в сети в этом документе , однако я рекомендую перезагрузку.

specialKevin
источник
Спасибо Кевину. (Не) к счастью, проблема давно ушла, поэтому я не могу проверить, но это выглядит как самый многообещающий вариант.
cagenut
3
В аналогичной проблеме, с которой я столкнулся, / sys / block / device-name / device / state уже был установлен на «выполняется», и приведенная выше команда не решила проблему.
Будет
3

Попробуйте использовать:

mount -o remount,rw /mnt/fo
Desperatuss0ccus
источник
Я знаю FreeBSD, а не Linux. Но для fBSD это mount -rw /mnt/foo, так что этот выглядит наиболее правильным для меня.
Крис С
1
У меня никогда не было этой работы в сценарии, изложенном в вопросе. Как только диск помечен только для чтения из-за ошибок, он всегда перезагружался для меня.
Алекс
1
Я отредактирую это в OP, но Алекс прямо здесь, проблема, кажется, находится ниже файловой системы: [root @ localhost ~] # mount -o remount, rw / mnt / foo mount: block device / dev / mapper / mpath0 защищен от записи, монтируется только для чтения
cagenut
1
Вы пытались размонтировать раздел и перемонтировать его? У меня были ошибки данных раньше с диском, размонтирование (или перемонтирование, rw) исправило это для меня. Это было с дисками SATA (и более ранними версиями EIDE / SCSI). Однако, в вашей ситуации мне интересно, если проблема в том, что канал диска должен быть сброшен. Мне интересно, если HDIO_DRIVE_RESET отправил через ioctl как-то. blockdev может использоваться для принудительного перечитывания таблицы разделов, которая может это сделать. IDE раскрывает это с помощью hdparm -w, возможно, с вашими приводами FC, у вас есть способ отправить ioctl на канал.
2

Я фанат предотвращения проблемы в первую очередь. Большинство корпоративных UNIX-блоков будут повторять операции файловой системы как всегда. Вам, как администратору, необходимо выполнить домашнюю работу перед настройкой конфигурации MPIO. Если ваше приложение должно подождать, пока устройство не вернется в рабочее состояние, вот решение. В вашем /etc/multipath.conf убедитесь, что для типа устройства, который вас интересует, для параметра «no_path_retry» установлено значение «очередь». Установка этого параметра приведет к тому, что неудачные операции ввода-вывода будут стоять в очереди, пока не будет найден правильный путь. Мы сделали это для того, чтобы наши боксы EMC Symmtrix / DMX работали с ошибками при определенных условиях сбой / восстановление пути диска / контроллера / srdf.

Этот подход сэкономил нам много раз и является нашим стандартом для сотен блоков в многоканальной / мультивендорной SAN с репликацией для аварийного восстановления.

Просто подумал, что могу поделиться со всеми вами. Береги себя.

TomF
источник
2

У меня была некоторая проблема, которую я решил, используя hdparm с -rопцией на подкаталогах логических, многолучевых устройств.

-r Получить / установить флаг только для чтения для устройства. Если установлено, Linux запрещает операции записи на устройстве.

c4f4t0r
источник
1

Как вы думаете, это связано с разделом этого документа, озаглавленным « Почему файловые системы ext3 в моей сети хранения данных (SAN) постоянно становятся доступными только для чтения ?»

Это довольно старая статья, в которой говорится о оптоволоконном канале, но это может быть связано с вашей проблемой.

Уникс Дворник
источник
Да, это не совсем конкретная ошибка, так как я использую гораздо более новые версии, чем те, на которые они ссылаются, но всевозможные подобные ситуации могут вызвать это. Мир волоконно-оптических каналов, hbas / hba-firmware / hba-drivers, микропрограммного обеспечения массивов, микропрограммного обеспечения коммутаторов, структуры матрицы, конфигурации устройства-сопоставления / многолучевого распространения, lvm и ext3 - это просто множество движущихся частей. Работайте в достаточном количестве сред, и вы увидите, что этот сценарий вызван множеством похожих, но не идентичных проблем. Вопрос под рукой, как восстановить / перемонтировать без перезагрузки.
cagenut
0

Повреждение файловой системы? Пытаться:

dumpe2fs /dev/c/c | grep Filesystem\

Если очистить с ошибками, то вам нужно сканировать и чистить.

codycook
источник
-4

Linux просто недостаточно хорошо справляется со средними и крупными сетями хранения данных. Вы ДОЛЖНЫ позаботиться об этом и точно настроить тайм-ауты ввода-вывода и обработку тайм-аута многолучевого распространения, все они в значительной степени соответствуют настольным настройкам по умолчанию.

(Помните «отклонение ввода-вывода на мертвое устройство»?)

darkfader
источник
1
Вы действительно должны сделать резервную копию таких утверждений, как «Linux не справляется с SAN» и «настройки по умолчанию для настольных ПК» со ссылками и неопровержимыми фактами.
Крис С
1
Тайм-аут ввода-вывода диска по умолчанию 30 секунд? Вышеуказанная тема? В заметке RedHat (как бы устаревшей) говорится, что они не могут изящно обрабатывать «Уведомление об изменении состояния» так, как это было бы задумано. Что Redhat по умолчанию поместил привязки многолучевого распространения в местоположение (/ var / lib), которое не было бы доступно во время загрузки драйвера многолучевого распространения? То, что вы не можете рекурсивно отключить горячее подключение PCI hba и временно автоматически отключить все зависимые LUN ​​до тех пор, пока они не будут заменены. То, что у него нет многопоточной инициализации HW и требуется «некоторое время», чтобы придумать> 1k лун. Удев, являющийся сценарием оболочки ...
darkfader