[dm-devel] 2.6.2-udm2

[Kevin Corry]

On Wednesday 18 February 2004 10:01, Patrick Mansfield wrote:
> On Wed, Feb 18, 2004 at 03:06:45PM +0100, Heinz Mauelshagen wrote:
> > On Wed, Feb 18, 2004 at 01:09:06PM +0000, Joe Thornber wrote:
> > > On Wed, Feb 18, 2004 at 01:01:29PM +0100, Heinz Mauelshagen wrote:
> > > > We can and will need to mlockall() the path test tool, which will
> > > > make sure that we can access all pages of the tool, shared library or
> > > > mmap'ed file it needs.
> > >
> > > Yes, I think Christophe Varoqui who is writing the tools is aware of
> > > this.
> > >
> > > > But if *all* paths of the multipath target to test are failed
> > >
> > > Then we error the ios, we have no choice.  The userland tester should
> > > not wait until this situation before testing.
> >
> > Right, but it won't have a chance to test early enough worst case.
> >
> > Eg, all phyiscal paths fail because of a short power outage to multiple
> > switches in a fabric, which come back online shortly later when all paths
> > have been failed by the multipath target.
>
> We ought to support both methods: allow fail or suspend when no paths are
> available, and not pick one or the other in the kernel. And for now,
> support whatever is easiest.

Suspending a device is handled by the DM core, and is normally only initiated 
by a command from user-space. I don't think the mpath module should be 
calling out to the core to suspend itself.

> Allowing suspend on no paths available also makes dm multipath very useful
> for single path cases where we want to allow hot replacement of the
> transport without having to umount or shutdown users of the disk.
>
> For example, if you need to replace a failing cable.

This should already work. If you're going to replace a bad cable, use dmsetup 
to suspend the device (and hence flush any outstanding I/O), then replace the 
cable, then use dmsetup to resume the device. Since no I/O will have been 
sent to the device while its suspended, the path being down won't cause any 
errors and mpath won't fail the path.

Of course, suspending the device for that long a period is probably not wise 
to begin with, depending on the activity on that device. Suspends are 
generally meant to be very short. Pre-load the new device table, suspend the 
device, switch in the new table, resume the device. 

-- 
Kevin Corry
kevcorry at us.ibm.com
http://evms.sourceforge.net/