Test feedback 2.6.17.4+libata-tj-stable (EH, hotplug)

Test feedback 2.6.17.4+libata-tj-stable (EH, hotplug)

[Christian Pernegger]

I finally got around to testing 2.6.17.4 with libata-tj-stable-20060710.

Hardware: ICH7R in ahci mode + WD5000YS's.

EH: much, much better. Before the patch it seemed like errors were
only printed to dmesg but never handed up to any layer above. Now md
actually fails the disk when I pull the (power) plug. I'll try my bad
cable once I can find it.

Hotplug: Unplugging was fine, took about 15s until the driver gave up
on the disk. After re-plugging the driver had to hard-reset the port
once to get the disk back, though that might be by design.

The fact that the disk had changed minor numbers after it was plugged
back in bugs me a bit. (was sdc before, sde after). Additionally udev
removed the sdc device file, so I had to manually recreate it to be
able to remove the 'faulty' disk from its md array.

Thanks for a great patch! I just hope it doesn't eat my data :)

C.

Re: Test feedback 2.6.17.4+libata-tj-stable (EH, hotplug)

[Tejun Heo]

Christian Pernegger wrote:
> The fact that the disk had changed minor numbers after it was plugged
> back in bugs me a bit. (was sdc before, sde after). Additionally udev
> removed the sdc device file, so I had to manually recreate it to be
> able to remove the 'faulty' disk from its md array.

That's because md is stilling holding onto sdc in failed mode.  A 
hotplug script which checks whether a removed device is in md array and 
if so removes it from the array will solve the problem.  Not sure 
whether that would be the correct approach though.

Thanks.

-- 
tejun

Re: Test feedback 2.6.17.4+libata-tj-stable (EH, hotplug)

[Bill Davidsen]

Christian Pernegger wrote:

> I finally got around to testing 2.6.17.4 with libata-tj-stable-20060710.
>
> Hardware: ICH7R in ahci mode + WD5000YS's.
>
> EH: much, much better. Before the patch it seemed like errors were
> only printed to dmesg but never handed up to any layer above. Now md
> actually fails the disk when I pull the (power) plug. I'll try my bad
> cable once I can find it.
>
> Hotplug: Unplugging was fine, took about 15s until the driver gave up
> on the disk. After re-plugging the driver had to hard-reset the port
> once to get the disk back, though that might be by design.
>
> The fact that the disk had changed minor numbers after it was plugged
> back in bugs me a bit. (was sdc before, sde after). Additionally udev
> removed the sdc device file, so I had to manually recreate it to be
> able to remove the 'faulty' disk from its md array.
>
> Thanks for a great patch! I just hope it doesn't eat my data :) 

And thank you for testing!

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: Test feedback 2.6.17.4+libata-tj-stable (EH, hotplug)

[Neil Brown]

On Tuesday July 11, htejun@gmail.com wrote:
> Christian Pernegger wrote:
> > The fact that the disk had changed minor numbers after it was plugged
> > back in bugs me a bit. (was sdc before, sde after). Additionally udev
> > removed the sdc device file, so I had to manually recreate it to be
> > able to remove the 'faulty' disk from its md array.
> 
> That's because md is stilling holding onto sdc in failed mode.  A 
> hotplug script which checks whether a removed device is in md array and 
> if so removes it from the array will solve the problem.  Not sure 
> whether that would be the correct approach though.

Checking whether the to-be-removed device is in an md array or in use
in any other way first definitely sounds like the right approach to
me.

Exactly what to do if the device is in use is somewhat less obvious.
If the array is completely quiescent then you don't necessarily want
to fail/remove the device from the array....

I think the best approach would be to have plug-ins that are called if
an unplugged device is in use, and if it is still in use after those
calls, then don't delete the device.  Maybe it would also be good if
hotplug was told when a device was no longer in use so it could remove
the /dev entry then....

NeilBrown