We recently were presenting a 1.0 TB SAN lun to two HBAs on a single Linux server. multipathd was managing the device files (two) and creating it's own device file(s) in /dev/mapper/ .

A couple of weeks ago, the filesystem on the lun experienced data corruption, and the LUN was UNpresented to the server after I made sure the filesystem wasn't mounted. We also started seeing what you'd expect in /var/log/messages - multipath entries reporting that readsector0 showed a path as down - the /dev/sd* devices corresponding to that LUN. (Specifically, /dev/sdl and /dev/sdz.)

Shortly after, the san admins rebuilt the lun with a new size. It is now 950 GB. When they re-presented the lun to the server, you could see the error messages about /dev/sdz and /dev/sdl cease, because the path was now reported as back up.

However, both 'multipath -ll' and 'fdisk /dev/sdz' show a size of 1.0 TB. Our SAN admin is fairly confident that the lun should only appear to be 950 GB large.

This is a very important production Oracle server and I don't want to interrupt write access to files in /dev/mapper, or in general, cause any kind of service disruption.

Can someone suggest a methodology by which I can make the system realize the correct size of the LUN without any interruption of service?

If this is not possible, is it safe to simply do a mkfs.ext3 on the multipath device, and ensure that the created filesystem is no larger than 945 GB or so? (Using the block-count and block-size arguments)

Thanks much.

[FOLLOW-UP]

After thinking through this a little more clearly, I'm quite sure that the old path and devices are "stale". I did a 'multipath -d' and sure enough there's a LUN with a new UUID out there:

# multipath -d
backup: remove (wwid changed)
create: backup (3600508b4000cf2f200008000015d0000) HP,HSV400
[size=1.0T][features=0][hwhandler=0][n/a]
\_ round-robin 0 [prio=0][undef]
\_ 0:0:0:12 sdl 8:176 [undef][ready]
\_ round-robin 0 [prio=0][undef]
\_ 1:0:0:12 sdz 65:144 [active][ready]

I'm fairly confident that is the LUN our san admin created for me. Unfortunately, multipath -d shows that it is still 1.0 TB. Fingers crossed - maybe on the SAN side it's actually 1 TB. I don't want to do anything until I can resolve the discrepancy. Perhaps there's still an underlying issue with the device files? Is there any remote chance I could run /sbin/start_udev and get the /dev/sd* files properly rebuilt without totally hosing the system?

Flush out the old multipath maps with 'multipath -F'.

Is there a reason you're using readsector0? I think the path_checker you should be using is tur. Feel free to post a snippet of your multipath.conf.

Thanks for the reply Jessica.

If I had to resort to this, I was thinking about doing:

multipath -f backup
multipath backup

(/dev/mapper/backup was the device file)

Would that be acceptable, while causing minimal interference?

To your second point - I am using readsecotr0 because back when I set this up, I was learning as I was going. I used the default comments section in multipath.conf simply because I didn't know of better and safe options.

Aside from a bunch of 'wwid' and 'alias' directives, here's the meat of the config file:

defaults {
user_friendly_names yes
udev_dir /dev
polling_interval 5
selector "round-robin 0"
path_grouping_policy failover
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout /bin/true
path_checker readsector0
rr_min_io 100
max_fds 8192
rr_weight priorities
failback immediate
no_path_retry fail
}

I have tur is a better checker to be using, but at this point I can't be making changes that aren't dire. If there is any service interruption to Oracle or the apps running on it in the next three months, heads would roll.