Это относительно распространенная проблема, когда что-то идет не так в SAN для 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
Все хорошо, теперь выдергиваю ЛУН из-под него.
[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
Как он до сих пор помнит, что там был тот «бар» файл… загадка, но сейчас не важна. Теперь я повторно представляю 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
Неееееееет.
Я пробовал всевозможные команды mount / tune2fs / dmsetup, и я не могу понять, как заставить его снять отметку с блочного устройства как защищенного от записи. Перезагрузка исправит это, но я бы предпочел сделать это онлайн. Час поиска в Google тоже ни к чему не привел. Спаси меня ServerFault.
Я совсем недавно столкнулся с этой проблемой и решил ее перезагрузкой, но после дальнейшего исследования выяснилось, что выполнение следующей команды может исправить это.
echo running > /sys/block/device-name/device/state
Я думаю, тебе стоит взглянуть на посмотрите раздел 25.14.4: Изменение состояния чтения / записи онлайн-логического устройства в этом документеОднако я рекомендую перезагрузку.
Попробуйте использовать:
mount -o remount,rw /mnt/fo
У меня была проблема, которую я решил с помощью hdparm с -r опция на поддисках логических многопутевых устройств.
-r Получить / установить флаг только для чтения для устройства. Если установлено, Linux запрещает операции записи на устройстве.
Я сторонник предотвращения проблемы в первую очередь. Большинство корпоративных UNIX-систем будут повторять операции файловой системы бесконечно. Вы, как администратор, должны выполнить некоторую домашнюю работу перед настройкой конфигурации MPIO. Если ваше приложение должно подождать, пока устройство не вернется в рабочее состояние, то вот решение. В вашем /etc/multipath.conf убедитесь, что для интересующего вас типа устройства для параметра «no_path_retry» установлено значение «queue». Установка этого параметра приведет к тому, что неудачные операции ввода-вывода будут помещены в очередь до тех пор, пока не будет указан допустимый путь. Мы сделали это, чтобы наши блоки EMC Symmtrix / DMX работали с ошибками при определенных условиях сбоях / восстановлении пути диск / контроллер / srdf. Когда вы хотите вывести устройство из строя вручную во время сбоя, это становится более сложным, поскольку вам нужно будет использовать такие инструменты, как dmsetup, для сброса / сбоя операций ввода-вывода или временного изменения файла multipath.conf и повторного сканирования устройств ... и т. Д.
Такой подход спас нам бесчисленное количество раз и является нашим стандартом для сотен ящиков в сети хранения данных с несколькими кабинетами и поставщиками с репликацией для аварийного восстановления.
Просто подумал, что могу поделиться со всеми вами. Береги себя.
Как вы думаете, это связано с раздел в этом документе под названием Почему файловые системы ext3 в моей сети хранения данных (SAN) постоянно становятся доступными только для чтения?
Это довольно старая статья, в которой говорится о волоконно-оптическом канале, но это может быть связано с вашей проблемой.
Повреждение файловой системы? Пытаться:
dumpe2fs /dev/c/c | grep Filesystem\
Если чистить с ошибками, то нужно сканировать и чистить.
Linux просто недостаточно хорошо справляется со средними и крупными сетями хранения данных. Вы ДОЛЖНЫ проявить некоторую осторожность и точно настроить тайм-ауты ввода-вывода и обработку тайм-аута многопутевого доступа, все они в значительной степени соответствуют настройкам по умолчанию для настольных компьютеров.
(Помните «отклонение ввода-вывода на мертвое устройство»?)