Вопросы Теги

Как Вы повторно монтируете ext3 чтение-запись фс после того, как оно будет смонтировано только для чтения от ошибки диска?

Если Вы хотите просто проверить с помощью ping-запросов IPv4 (полезный для нахождения IP FQDN), затем просто прикрепляют-4 на конец Вашего запроса ping. Например:

ping example.com -4

Действительно не объясняет, почему Вы получаете разрешение IPv6, когда оно отключено хотя...

18
задан 19 March 2010 в 17:38
7 ответов

Использование попытки:

mount -o remount,rw /mnt/fo
3
ответ дан 2 December 2019 в 20:26
  • 1
    Я знаю FreeBSD, не Linux. Но для fBSD it' s mount -rw /mnt/foo, таким образом, этот выглядит больше всего правильным мне. –  Chris S 19 March 2010 в 02:27
  • 2
    У меня никогда не было этой работы в сценарии, обрисованном в общих чертах в вопросе. После того как диск отмечен только для чтения из-за ошибок, он всегда брал перезагрузку для меня. –  Alex 19 March 2010 в 02:52
  • 3
    I' ll редактируют это в OP, но Alex прямо здесь, проблема, кажется, ниже файловой системы: [root@localhost ~] # монтирует, что-o повторно монтируются, rw/mnt/foo монтируются: блочное устройство/dev/mapper/mpath0 защищено от записи, монтируясь только для чтения –  cagenut 19 March 2010 в 17:37
  • 4
    Вы попытались размонтировать раздел и повторно смонтировать его? I' ve имел ошибки данных прежде с диском, размонтировавшись (или повторно смонтируйтесь, rw), зафиксировал его для меня. Это было с дисками SATA (и более старый EIDE/SCSI) Однако в Вашей ситуации, я задаюсь вопросом, является ли проблема то, что дисковый канал должен быть сброшен. I' m задающийся вопросом, если HDIO_DRIVE_RESET, отправленный через ioctl так или иначе. blockdev может использоваться для принуждения перечитывания таблицы разделов, которая могла бы сделать это. IDE выставляет это с hdparm-w, возможно, с Вашими дисками FC, you' ve получил способ отправить ioctl на канал. –   20 March 2010 в 02:38

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

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

1
ответ дан 2 December 2019 в 20:26
  • 1
    Да, не, что точная определенная ошибка начиная с I' m выполнение намного более новых версий, чем те они ссылаются, но все виды аналогичных ситуаций могут вызвать его. Мир волоконно-оптического канала, hbas/hba-firmware/hba-drivers, выстраивает встроенное микропрограммное обеспечение, переключает встроенное микропрограммное обеспечение, дизайн матрицы, device-mapper/multipathd конфигурация, lvm, и ext3 является просто большим количеством подвижных частей. Работа над достаточным количеством сред и you' ll видят этот сценарий, вызванный мешком захвата подобных, но не идентичных проблем. Вопрос под рукой, как восстанавливаться/повторно монтировать без перезагрузки. –  cagenut 19 March 2010 в 19:35

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

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

-4
ответ дан 2 December 2019 в 20:26

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

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

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

6
ответ дан 2 December 2019 в 20:26

I am a fan of preventing the issue in the first place. Most enterprise UNIX boxes will retry filesystem operations like forever. You as an administrator need to do some homework before tuning your MPIO configuration. If your application should wait until the device return to a usable state, then here is a solution. In your /etc/multipath.conf make sure that the device type you care about has a setting for "no_path_retry" set to "queue". Setting this will cause failed I/Os to queue until there is a valid path. We have done this for our EMC Symmtrix/DMX boxes to work about hiccups under certain conditions drive/controller/srdf path failures/recovery. When you want to fail the device manually during a failure it gets more complicated as you will need to use tools like dmsetup to flush/fail I/Os or temporarily change the multipath.conf file and rescan devices....etc.

This approach has saved our bacon countless times and is our standard for hundreds of boxes on a multicabinet/multivendor SAN with replication for disaster recovery.

Just thought I might share with you all. Береги себя.

2
ответ дан 2 December 2019 в 20:26

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

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

2
ответ дан 2 December 2019 в 20:26

Повреждение файловой системы? Попробуйте: 

dumpe2fs /dev/c/c | grep Filesystem\

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

0
ответ дан 2 December 2019 в 20:26

Теги

Похожие вопросы