I came across the following from the ext3-users mailing list. The poor user was stuck on a never-updated RHEL 3 production server and running into kernel panic problems. He was advised to try updating to the latest kernel rpm from Red Hat, but he didn’t feel he could do that. In his words:
I’m caught between a rock and a hard place due to the EMC PowerPath binary only kernel crack. Which makes it painful to both me and my customers to regularly upgrade the kernel. Not to mention the EMC supportability matrix of doom.
That pretty much sums it all up right there.
The good news is that I’ve been told that dm-multipath is almost at the point where it has enough functionality to replace PowerPath. Of course, that version isn’t yet shipping in distributions, and I’m sure it needs more testing, but it’ll be good when enterprise users who need this functionality can move to a 100% fully open source storage stack.
About the only thing left to do is to work in a mention of the Frying Pan of Doom
No related posts.
February 25th, 2009 at 5:31 pm
Yes, the multipath userspace code is badly in need of another release. The last one being 18 months ago requires patches to work-out-of-the-box with current udev.
February 25th, 2009 at 10:55 pm
I tried to get a simple multipath going with 2 FC controllers, but couldn’t get anything to work. This is an area that needs a lot of user-facing work. For instance, blacklisting everything by default seems pretty silly.
February 26th, 2009 at 2:40 am
How old is RHEL 3? Do you still get updates from Redhat?
February 27th, 2009 at 7:01 pm
It’s only a problem because linux devs make it one by not having a stable API.
February 27th, 2009 at 11:03 pm
@4: linuxhater,
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.
February 28th, 2009 at 8:14 am
We have a lot of installations of RHEL 4 and both dm-multipath and PowerPath (and some of oracle enterprise linux). And no issues so far…
March 15th, 2009 at 11:01 pm
This may not be revelant but i figured i’d post this anyway. If you’re using ubuntu 8.10 you may be in for some issues with the network manager. For some unknown reason it stops functioning. You will need to manually set you’re resolv.conf with your ISP’s DNS servers. That file is located in /etc/network/resolv.conf
April 7th, 2009 at 3:54 pm
@Durga
As per http://www.redhat.com/security/updates/errata/ RHEL3 has been released on October 23, 2003 and is supported until October 31, 2010. Not sure whether any new minor release is planned however but Red Hat still provides security errata.
December 17th, 2009 at 7:57 pm
Hey,
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.
December 18th, 2009 at 11:25 am
darkfader ,
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?