Message ID | 200907081415.39925.knikanth@suse.de (mailing list archive) |
---|---|
State | RFC, archived |
Delegated to: | Alasdair Kergon |
Headers | show |
On Wed, Jul 08, 2009 at 02:15:39PM +0530, Nikanth Karthikesan wrote: > From: Hannes Reinecke <hare@suse.de> > Subject: Allow zero paths for multipath priority groups > > For correct handling of the all-paths-down scenario we have to > allow zero paths as a valid argument for priority groups. That seems counter-intuitive. Can you be more specific, with example scenarios? Alasdair -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Alasdair G Kergon wrote: > On Wed, Jul 08, 2009 at 02:15:39PM +0530, Nikanth Karthikesan wrote: >> From: Hannes Reinecke <hare@suse.de> >> Subject: Allow zero paths for multipath priority groups >> >> For correct handling of the all-paths-down scenario we have to >> allow zero paths as a valid argument for priority groups. > > That seems counter-intuitive. > Can you be more specific, with example scenarios? > Currently we're not allowing the last path to be removed from a multipath target. With earlier kernel revisions this wasn't a problem as dev_loss_tmo didn't work correctly and so in effect no devices were ever removed from the system. However, with newer kernels dev_loss_tmo works correctly, so any dead path will be removed from the system. So when the last path goes down, we're having a stale reference to an sdev which for all intents and purposes should have been removed. And even worse, when this path comes back the SCSI subsystem isn't even able to assign it to the old device number, as this is already taken. Cheers, Hannes
Then effectively the multipath target with no paths turns into a pure queueing target. I'll have a think about the options, but that's probably quite a reasonable idea. Alasdair -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Alasdair G Kergon wrote: > Then effectively the multipath target with no paths turns into a pure > queueing target. I'll have a think about the options, but that's probably > quite a reasonable idea. > Quite so. Cheers, Hannes
Index: linux-2.6-dm/drivers/md/dm-mpath.c =================================================================== --- linux-2.6-dm.orig/drivers/md/dm-mpath.c +++ linux-2.6-dm/drivers/md/dm-mpath.c @@ -787,8 +787,8 @@ static int multipath_ctr(struct dm_targe { /* target parameters */ static struct param _params[] = { - {1, 1024, "invalid number of priority groups"}, - {1, 1024, "invalid initial priority group number"}, + {0, 1024, "invalid number of priority groups"}, + {0, 1024, "invalid initial priority group number"}, }; int r;