[dm-devel] 2.6.2-udm2

[Patrick Mansfield]

On Wed, Feb 18, 2004 at 10:58:42AM -0600, Kevin Corry wrote:
> On Wednesday 18 February 2004 10:47, Joe Thornber wrote:
> > On Wed, Feb 18, 2004 at 10:34:19AM -0600, Kevin Corry wrote:
> > > 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.
> >
> > It's not just about keeping the suspend period short, the preloading
> > of a table is the bit that requires memory allocations.
> 
> Yes, but in the example Patrick mentioned, there wouldn't be any new table to 
> load (assuming when the cable is switched it doesn't suddenly show up as a 
> different device). It would simply be a suspend followed by a resume, with 
> the intention of preventing mpath from detecting I/O errors.

(At least long term) we would want to allow the device to show up even on
a different path/sd, for example, so you can utilize a spare host adapter
or connector - a lot of cards are dual ported, and I assume many SATA/SAS
adapters will be dual ported.

I was assuming all path(s) had failed, the bad component was found and
replaced, and so there is no chance to quiesce dm before the replacement.
The same would apply to hot replacement of a failed PCI adapter card.

> My point was that suspending a device for the length of time needed to 
> physically change a cable could lead to memory starvation.

Yes, but memory starvation (that will be recovered from) is better than an
oops, and in some cases better than application downtime.

-- Patrick Mansfield