Kernel notification when FC paths are added/removed

6 views
Skip to first unread message

Mandy Kirkconnell

unread,
Jul 12, 2012, 7:54:03 PM7/12/12
to ata-scsi-dev@lists.apple.com list
Hi,

I have a 10.7 system attached to 2 FC controllers on a RAID. I'm seeing
horrible performance, since there is only one device per LUN in 10.7 (as
opposed to one device per controller in 10.6). I can see that the I/O is
flipping back and forth across the controllers - creating horrible LUN
thrashing.

I have created an application that uses mpioutil to disable all physical
paths to a given controller, forcing the I/O to use only ONE controller.
That helps with the performance issue. However, my problem is that my
kext does not get any notification from the kernel when an underlying
physical FC path is added or removed to either controller (via a FC switch).

For example, say I have 2 physical FC paths to each controller. I
disable the paths on one controller (2037,2047) via mpioutil, so I have
something like this:

/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20360080E52E2BB400000001 Active
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20460080E52E2BB400000001 Active
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20370080E52E2BB400000001 Disabled
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20470080E52E2BB400000001 Disabled

This forces the I/O to use the controller with WWNN 2036 and 2046. Then
say I lose one of the Disabled paths for some reason (flakey cable, etc).

/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20360080E52E2BB400000001 Active
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20460080E52E2BB400000001 Active
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20370080E52E2BB400000001 Disabled

Now the path comes back, but I get no notification from the kernel since
the device already exists (so we don't need a probe or anything). Now I
have:

/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20360080E52E2BB400000001 Active
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20460080E52E2BB400000001 Active
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20370080E52E2BB400000001 Disabled
/dev/rdisk-xvm-20070080e52e2bb4-002 60080E50002E2BB4000003ED4FDB7878
20470080E52E2BB400000001 Active

Which is NOT what I want... back to LUN thrashing and horrible
performance :( I need a way to get the kernel to notify my kext when a
path appears or disappears. Is there some hook into the kernel to
request such a notification??

This entire 10.7 path management is a complete nightmare for storage
developers. I understand Apple is trying to make things transparent to
the user (ie. dumb it down) but anyone who knows anything about storage
or performance would NOT have written the backend 10.7 kernel code this
way. Round robin between the controllers, with no way to control the
paths, is NOT a good model. This is forcing us to call up to userspace
to call mpioutil for every path change. When a system has 1000+ paths,
this takes forever!! I would really like to have a kernel API provided,
or least access to the mpioutil code... either would be extremely
helpful (especially an API).

Note that ALUA mode is not an option on most of our RAIDS.

I realize I could use zoning on the FC switch to separate each
controller to force I/O to a given controller... but that does not work
for path failover. I need to have access to both controllers for high
availability... and have only ONE controller being accessed at a time.

Any help or advice would be greatly appreciated!!

Thanks,

Mandy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Ata-scsi-dev mailing list (Ata-sc...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/ata-scsi-dev/ata-scsi-dev-garchive-72467%40googlegroups.com

This email sent to ata-scsi-dev-...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages