The question was whether or not EMC supported dm-multipath; especially while Ric Wheeler was at EMC, they were pretty good about trying to help work with the open source world. The issue was that EMC wasn’t necessarily certifying their closed-source drivers and products to work with specific kernel versions, such as when RHEL 3 needed to issue a security update to the kernel, in a sufficiently expeditious way. That’s not necessarily a knock on EMC, since RHEL 3 is an ancient distribution, and it’s hard to have a product team leap into action every time there is a new kernel release. But it shows the problem having binary, out-of-tree device drivers. Even if the driver worked just fine, it wouldn’t be certified by EMC, which means the support folks might not help you if it caused problems — and who wants to be the customer that gambles with their data whether or not PowerPath works with a new security updated kernel?

to me, this seems to be mostly an issue of uninformedness.
emc supports dm-multipath on 2.6 kernels, and that’s been the case for quite some time now.
I’m not sure as of the reason he was stuck on RHEL3, but definitely, it is NOT because of EMC or PowerPath. As I know from the linux symposium notes of like 3 years ago, EMC has actually done quite a lot to help mature dm-multipath.

As someone who has the “pleasure” of using linux in setups with >1k+ disks on some servers, I can just wish the multipath devs invested some more work into the userspace framework which is mostly unchanged (how about sorting the multipath output?) since 2006 and too heavily relies on stuff like (outside the sourcecode) undocumented defaults (for i.e. array settings).

It is nice to hear though that there might be some under-the-hood improvements to multipath. right now it is like… better basic functionality than the one in windows, worse architecture, less elegant than aix, not as outdated core and concepts than powerpath, and lotsa less robust than hp-ux, and totally far from a dream like VxDMP (i’ve seen all of them die and choke at times, so I can compare quite ok)

I hope over time more vendors go the way EMC went and supply driver modules for their specifics instead of wasting time on proprietary drivers, but that’ll only work if the multipath development leeps their pace.

There are tradeoffs with having internal kernel API’s being frozen in concrete. Linus derives a lot of advantages in being able to optimize its internal interfaces for best performance as technology and requirements change. It has a fixed userspace API, of course, but what happens underneath the system call layer is something that the Linux development community has decided it is highly important that we have the freedom to improve it to make the most functional and performant kernel possible.