Вопрос: Как повторно установить ext3 fs readwrite после того, как он будет монтирован только с диска из-за ошибки?


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

Как он все еще помнит, что файл «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, и я не могу понять, как заставить его отключить блочное устройство как защищенное от записи. Перезагрузка будет исправлена, но я бы скорее сделал это в режиме онлайн. Час поискового робота тоже меня ничуть не изменил. Сохраните мне ServerFault.


17
2018-03-18 22:41


Источник


хм, пару вопросов «Это относительно общая проблема, когда что-то не так в SAN»  почему ваша SAN такая ненадежная, я бы сначала это проверил? Вы пробовали просто размонтировать с помощью umount, а затем снова установить его? Есть ли веская причина, почему вам нужно сделать перезагрузку ?. Обычно мне нужно только перезагрузить мои корневые файловые системы после поддержания. - The Unix Janitor
umount отскакивает от открытых дескрипторов файлов, которые часто происходят из процессов, которые вы бы скорее выбрали. - cagenut
У меня есть аналогичная проблема, когда после проблемы SAN виртуальные диски только для чтения, и попытка повторного подключения вызывает ту же ошибку в OP. VM находятся на esxi 4.1 с хранением волоконных каналов. Проблема перезагрузки VM устраняет проблему. Я лично не считаю, что это связано с многолучевым распространением. Конечно, должен быть способ исправления без перезагрузки, тем более что некоторые службы (apache) имеют тенденцию работать только на FS только для чтения. - Will
Я пришел сюда, чтобы найти решение моей собственной проблемы (что другое, поврежденный диск). Вместо этого я улыбнулся. +1 для «Черт, ты» - user1207217
У меня такая же проблема, как и у меня, но я использую LVM. Тот же lvdisplay дал бы мне «прочитать не удалось после 0 из 4096 в 449197309952: Ошибка ввода / вывода», пока я не выполнил «multipath -r», тогда LVM начал показывать все правильно без ошибок. Тем не менее, я все еще не могу восстановить раздел. Невозможно отключить либо, говорит, что устройство занято. Если я выключу все процессы с помощью устройства, я могу размонтировать, а затем снова смонтировать, но я бы предпочел просто перемонтировать устройство для чтения-записи, поскольку я должен уметь ... - mpontes


Ответы:


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

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

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


6
2018-02-07 22:27



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


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

mount -o remount,rw /mnt/fo

3
2018-03-19 00:02



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


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

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

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


2
2017-09-13 20:10





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

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


2
2017-12-12 19:43





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

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


1
2018-03-18 23:13



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


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

dumpe2fs /dev/c/c | grep Filesystem\

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


0
2018-02-07 00:19





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

(Помните «отклонение IO к мертвому устройству»?)


-4
2017-10-17 12:19



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