On Fri, 2008-07-25 at 09:48 +0200, Domenico Viggiani wrote: > I totally agree. > I know that dm-multipath is opensource and if a feature is missing you can > code it by yourself (!) but Red Hat is not opensource and could add it to > (the top of) users wishlist. > Well, I think you have a misunderstanding here: Red Hat absolutely is Open Source. Red Hat Enterprise Linux is licensed under GPL with the exception of the Trademarks and Logos.
Red Hat also has a very strong upstream commitment which means that Red Hat does generally develop new functionality within the upstream community *before* including them in a product. You are right though that Red Hat's development is driven by the customer requirements. This is a core part of the value of a Subscription: as a customer you can provide input for future development and tell Red Hat what to contribute into the upstream community. Of course, we have to prioritize based on a number of factors, so it is not always evident and direct. > Tom, why do you not subscribe to dm-devel and try to post a message for an > update on this? > I will follow and reply. Peraphs we'll get more attention. > We always encourage direct participation in upstream development. So if you have the capability to do so, I strongly encourage this. In addition, you should contact Red Hat Support and provide them with the a RFE containing the use-case, a business justification and requirements. We then can review that for RHEL6 and possibly for a backport (although that is very limited). Regards, Daniel > Thanks > Domenico Viggiani > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Sightler > > Sent: Thursday, July 24, 2008 9:40 PM > > To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list > > Subject: RE: [rhelv5-list] RE: multipathing in RHEL5 > > > > On Thu, 2008-07-24 at 11:25 -0700, Collins, Kevin [Beeline] wrote: > > > Aren't most people running LVM where you can just add a new > > LUN, pvcreate and vgextend? > > > > I'm sure they are, but I believe that's a little bit of a > > crutch that Redhat and other Linux developers are using to > > try to make this seem less critical. > > > > Most storage arrays make it very easy to simply grow an > > existing LUN on the fly and the OS needs to easily support > > online growth of volumes in this case. That other OS from > > Redmond has supported online growth in this way since, with > > the exception of system volumes, since at least their 2000 > > version. It seems a shame that Linux can't do it. > > > > Forcing admins to add LUN's to grow a volume removes from > > them the ability to be more conservative and granular with > > their expansions because otherwise they end up being forced > > to manage a large number of LUN's even with a relatively few > > systems. I have a couple of dozens servers that have been on > > the SAN for 5+ years. They've probably had their volumes > > grown and average of once a year in that time. If I always > > added a LUN I would now have to manage 125 LUN's just for those > > 25 servers for no reason other than it's the only way to grow > > them online. > > > > It can also significantly complicate the implementation of > > storage array based snapshots, especially on some platforms > > that won't guarantee consistent snaps across multiple LUN's. > > IMO, it's a feature that Linux really needs. > > _______________________________________________ > rhelv5-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv5-list -- Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc. E-Mail: [EMAIL PROTECTED], http://www.redhat.com/ Key-FP: 3DD7 C376 C3E0 1917 9A63 6343 5A26 2C59 6C07 6F32 _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
