Custom priority callout
I know that the issue with writing custom priority callouts is that they
need to be running in RAM so that if the disk is lost, it can be called again. My question is, if I write a custom binary file, and statically compile it so it doesn't link against any libraries, does multipath automatically load it into RAM because it mentioned in the config file, or is their other code that has to be modified to load it. Thanks. --- Jim Lester | Linux Product Specialist Jim.Lester@Compellent.com (o) 952.294.2802 (c) 763.218.6012 Compellent Technologies | www.compellent.com -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel |
Custom priority callout
On Wed, Aug 13, 2008 at 09:32:27AM -0500, Jim Lester wrote:
> I know that the issue with writing custom priority callouts is that they > need to be running in RAM so that if the disk is lost, it can be called > again. > > My question is, if I write a custom binary file, and statically compile > it so it doesn't link against any libraries, does multipath > automatically load it into RAM because it mentioned in the config file, > or is their other code that has to be modified to load it. It will most certainly be evicted from memory. You might be better of using the more recent versions of multipath and making your custom priority callout as one of the libraries in the 'libprio' directory. You will need to modify the Makefile and the libprio.c to include your code. Keep in mind if you segfault in it you will bring down multipathd with it. Oh, and do post it on this mailing list so that multipath can nativly support the Compellant path priority code (I thought it was multibus??) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel |
Custom priority callout
Compellent SANs can do a mix of both Fibre connections and iSCSI
connections to the same volume. So some of our customers are looking for ways to do more complex set ups with iSCSI as a failover situation behind multiple fibre connections. Multibus works fine if they are using like connections, but if not, we wanted to be able to make sure that the faster connections come up on top. --- Jim Lester -----Original Message----- From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On Behalf Of Konrad Rzeszutek Sent: Wednesday, August 13, 2008 9:52 AM To: device-mapper development Subject: Re: [dm-devel] Custom priority callout On Wed, Aug 13, 2008 at 09:32:27AM -0500, Jim Lester wrote: > I know that the issue with writing custom priority callouts is that they > need to be running in RAM so that if the disk is lost, it can be called > again. > > My question is, if I write a custom binary file, and statically compile > it so it doesn't link against any libraries, does multipath > automatically load it into RAM because it mentioned in the config file, > or is their other code that has to be modified to load it. It will most certainly be evicted from memory. You might be better of using the more recent versions of multipath and making your custom priority callout as one of the libraries in the 'libprio' directory. You will need to modify the Makefile and the libprio.c to include your code. Keep in mind if you segfault in it you will bring down multipathd with it. Oh, and do post it on this mailing list so that multipath can nativly support the Compellant path priority code (I thought it was multibus??) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel |
Custom priority callout
On Wed, Aug 13, 2008 at 09:57:22AM -0500, Jim Lester wrote:
> Compellent SANs can do a mix of both Fibre connections and iSCSI > connections to the same volume. So some of our customers are looking for > ways to do more complex set ups with iSCSI as a failover situation > behind multiple fibre connections. Nice. I would suggest you develop a library implementation and post it here. This way it could be integrated in all of the Linux distributions over time and your customers won't have to download a package. > > Multibus works fine if they are using like connections, but if not, we > wanted to be able to make sure that the faster connections come up on > top. I am curious how you are going to figure this out on the iSCSI connection? Nop-out latency? -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel |
Custom priority callout
By "faster" I just meant conceptually, fibre->iSCSI HBA->iSCSI software.
I didn't have any intention of actually polling the link somehow. And I will absolutely post it back to the list once we get it written, I already posted the hardware table definition, so that should be working its way in here. --- Jim Lester -----Original Message----- From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On Behalf Of Konrad Rzeszutek Sent: Wednesday, August 13, 2008 11:43 AM To: device-mapper development Subject: Re: [dm-devel] Custom priority callout On Wed, Aug 13, 2008 at 09:57:22AM -0500, Jim Lester wrote: > Compellent SANs can do a mix of both Fibre connections and iSCSI > connections to the same volume. So some of our customers are looking for > ways to do more complex set ups with iSCSI as a failover situation > behind multiple fibre connections. Nice. I would suggest you develop a library implementation and post it here. This way it could be integrated in all of the Linux distributions over time and your customers won't have to download a package. > > Multibus works fine if they are using like connections, but if not, we > wanted to be able to make sure that the faster connections come up on > top. I am curious how you are going to figure this out on the iSCSI connection? Nop-out latency? -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel |
| All times are GMT. The time now is 05:57 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.