È un problema relativamente comune quando qualcosa non va in una SAN per ext3 per rilevare gli errori di scrittura del disco e rimontare il filesystem in sola lettura. Tutto bene, solo quando la SAN è fissa non riesco a capire come reinstallare il filesystem in lettura e scrittura senza riavviare.
Ecco:
[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
Va bene, ora tiro fuori il LUN da sotto di esso.
[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
Pensa solo di essere di sola lettura, in realtà non è nemmeno lì.
[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
Come si ricorda ancora che il file 'bar' è lì ... mistero, ma non è importante in questo momento. Ora presento nuovamente il 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]
Ottimo vero? Dice [rw] proprio lì. Non così in fretta:
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
OK, non lo fa automaticamente, gli darò solo una piccola spinta:
[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only
Al diavolo sei:
[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only
Noooooooooo.
Ho provato tutti i tipi di diversi comandi mount / tune2fs / dmsetup e non riesco a capire come farlo per annullare il contrassegno del dispositivo a blocchi come protetto da scrittura. Il riavvio lo risolverà, ma preferirei farlo online. Un'ora di googling non mi ha portato da nessuna parte. Salvami ServerFault.
3
hmm, un paio di domande 'È un problema relativamente comune quando qualcosa va storto in una SAN' perché la tua SAN è così inaffidabile, prima verificherei? Hai provato a smontare con umount e quindi a montarlo di nuovo? C'è una buona ragione per cui devi fare un rimontaggio ?. Di solito ho solo bisogno di rimontare i miei filesystem di root dopo la manutenzione.
—
The Unix Janitor
umount rimbalza su handle di file aperti, che spesso provengono da processi che preferiresti uscire con sicurezza.
—
Cagenut,
Ho un problema simile in cui dopo un problema SAN i dischi VM sono di sola lettura e il tentativo di rimontare provoca lo stesso errore nell'OP. Le macchine virtuali sono su esxi 4.1 con memoria a canale in fibra ottica. Il riavvio della VM risolve il problema. Personalmente non penso che questo abbia a che fare con multipath. Sicuramente ci deve essere un modo per risolvere senza riavviare, soprattutto perché alcuni servizi (apache) tendono a continuare a funzionare su un FS di sola lettura.
—
Sarà il
Sono venuto qui alla ricerca di una soluzione al mio problema (che è diverso, un disco corrotto). Invece ho sorriso. +1 per "Che diavolo sei"
—
user1207217
Ho lo stesso identico problema, ma sto usando LVM. Lo stesso lvdisplay mi darebbe una "lettura non riuscita dopo 0 di 4096 a 449197309952: errore di input / output" fino a quando non ho fatto un "multipath -r", quindi LVM ha iniziato a visualizzare tutto correttamente senza errori. Tuttavia, non riesco ancora a rimontare la partizione. Non è possibile nemmeno smontare, dice che il dispositivo è occupato. Se chiudo tutti i processi utilizzando il dispositivo, posso smontare e quindi rimontare con successo, ma preferirei solo essere in grado di rimontare il dispositivo in lettura-scrittura, come dovrei essere in grado di ...
—
mpontes