Its a relatively common problem when something goes wrong in a SAN for ext3 to detect the disk write errors and remount the filesystem read-only. Thats all well and good, only when the SAN is fixed I can't figure out how to re-re-mount the filesystem read-write without rebooting.

Behold:

[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

All good, now I yank the LUN out from under it.

[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

It only thinks its read-only, in reality its not even there.

[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

How it still remembers that 'bar' file being there... mystery, but not important right now. Now I re-present the 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]

Great right? It says [rw] right there. Not so fast:

[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system

OK, doesn't do it automatically, I'll just give it a little push:

[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

The hell you are:

[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

Noooooooooo.

I have tried all sorts of different mount/tune2fs/dmsetup commands and I cannot figure out how to get it to un-flag the block device as write-protected. Rebooting will fix it, but I'd much rather do it on-line. An hour of googling has gotten me nowhere either. Save me ServerFault.

link|improve this question
2  
hmm, couple of questions 'Its a relatively common problem when something goes wrong in a SAN' why is your SAN so unreliable, I'd check that out first? Have you tried just unmounting with umount, and then mounting it again? Is there a good reason why you need to do a remount?. I usually only need to remount my root filesystems after maintainace. – The Unix Janitor Mar 18 '10 at 23:00
umount bounces on open file handles, which are often from processes you'd much rather have exit sanely. – cagenut Mar 19 '10 at 15:47
feedback

6 Answers

Your problem is not the remounting, it's the multipath device which is still read-only.

link|improve this answer
yes I got that. the question is how to change it. – cagenut Apr 8 '10 at 15:53
@cagenut: No, that wasn't what you asked. That may be what you should have asked, though. – Teddy Apr 8 '10 at 17:18
1  
Right there in the post Teddy: "I cannot figure out how to get it to un-flag the block device as write-protected." – cagenut Apr 8 '10 at 22:30
feedback

mount -o remount,rw /mnt/fo

link|improve this answer
I know FreeBSD, not Linux. But for fBSD it's mount -rw /mnt/foo, so this one looks the most right to me. – Chris S Mar 19 '10 at 0:27
1  
I have never had this work in the scenario outlined in the question. Once the disk is marked read-only due to errors, it has always taken a reboot for me. – Alex Mar 19 '10 at 0:52
I'll edit this into the OP, but Alex is right here, the problem appears to be below the filesystem: [root@localhost ~]# mount -o remount,rw /mnt/foo mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only – cagenut Mar 19 '10 at 15:37
Have you tried unmounting the partition and remounting it? I've had data errors before with a drive, unmounting (or remount,rw) has fixed it for me. This was with SATA drives (and older EIDE/SCSI) However, in your situation, I am wondering if the issue is that the drive channel needs to be reset. I'm wondering if HDIO_DRIVE_RESET sent through ioctl somehow. blockdev can be used to force rereading of the partition table which might do it. IDE exposes this with hdparm -w, perhaps with your FC drives, you've got a way to send the ioctl to the channel. – deleted Mar 20 '10 at 0:38
feedback

I just recently ran into this problem and solved it by rebooting but after further investigation it appears issuing the following command might fix it.

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

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Storage_Administration_Guide/index.html#task_controlling-scsi-command-timer-onlining-devices

link|improve this answer
Thanks Kevin. (Un)fortunately the problem is long gone so I can't test but this looks like the most promising option. – cagenut Feb 9 at 17:11
feedback

Do you think it's related to

http://www.redhat.com/magazine/026dec06/features/tips_tricks/

see section on Why does the ext3 filesystems on my Storage Area Network (SAN) repeatedly become read-only?

it's quite an old article, and is talking about fibre channel. It may be related to your problem.

link|improve this answer
Yep, its not that exact specific bug since I'm running much newer versions than those they reference, but all sorts of similar situations can cause it. The world of fibre-channel, hbas/hba-firmware/hba-drivers, array firmware, switch firmware, fabric design, device-mapper/multipathd config, lvm, and ext3 is just plain a lot of moving parts. Work on enough environments and you'll see this scenario caused by a grab bag of similar but not identical problems. The question at hand is, how to recover/remount without rebooting. – cagenut Mar 19 '10 at 17:35
feedback

I have a similar situation. Fc connection to the disks was los, and now one volume can not be mounted rw. Iwas not able to fsck it as well. df -k, lsof, searching in /proc/mounts showed nothing about the volume beeing mounted or opened. then I've saved the device mapper settings for that volume: dmsetup table volume_map_name >> ~/somefile then I've created an other mapping using the previous file: dmsetup create testmapping ~/somefile

with this I was able to run fsck on it and next I was able to mount it rw.

well, I know this is not THE solution for you as you have mentioned that you prefer not to umount, but it can be a way to have that device accessible rw.

Have you found any other solution?

link|improve this answer
feedback

Linux simply doesn't cope well enough with medium-large scale SANs. You MUST give it some care and fine tune the IO timeouts and multipath timeout handling, they're all pretty much at desktop-ready defaults.

(Remember "rejecting IO to dead device"?)

link|improve this answer
You really need to backup statements like "Linux doesn't cope with SANs" and "desktop ready defaults" with references and hard facts. – Chris S Oct 17 '11 at 12:40
Default disk IO timeout of 30seconds? The above thread? The note from RedHat (outdated as it may) stating they cannot handle a "State change notification" gracefully, the way it would be intended. That Redhat by default put the multipath bindings in a location (/var/lib) that would not accessible at the load time of the multipath driver? That you can't recursively hot-disable a PCI hotplug hba and temporarly automagically take all dependant LUNs offline until it has been replaced. That it has no multithreaded HW init and takes "a while" to come up with >1k luns. Udev, being a shell script... – darkfader Oct 17 '11 at 15:18
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.