Grahame Kelly <grah...@wildpossum.com> writes:
>> From: Daniel Pittman <dan...@rimspace.net>
>> Grahame Kelly <grah...@wildpossum.com> writes:
[...]
>> That only handles the hot *UN*-plug side of things, and can cause
>> significant grief to you if the driver doesn't cope: anything from
>> several minutes in which *all* disks on that controller are unavailable
>> during error handling, through to a controller hang.
>
> Rather than stating what I suspect is just a "belief", have you look
> at the Kernel source code at all?
I am a little curious why you suspect this is "just a belief", but to
answer your question, yes. I /do/ know what the kernel does, as well as
having some idea of how various controllers handle (or fail to) the
hotplug events.
I even tested some improvements to the libata error handler, way back
when, when it turns out that I owned one of the controllers where a
little extra hand-holding in the error handler after a hotplug event.
> If so I would be very interested at exactly where you state such
> activity happens.
What, you mean hardware or drivers that don't cope? Well, the NVIDIA
SATA drivers had some problems that would cause a long, long delay
trying error recovery if a device got unplugged. IIRC, an inverted bit
in the sense data returned from the controller was responsible, but it
has been some time.
> According to Linux Internals Doco (and hereijn I refer to the Linux
> Drivers themselves) Once the device has been "un-mounted" the OS
> warrants that the device, its linked control blocks, buffers etc. are
> indeed-flushed and data secured on the device medium.
Sure. What that has to do with drivers that don't cope with error
recovery from a hot-unplug of a device, though, I don't quite follow.
[...]
>> After all, you don't want /dev/sdb hanging about when the disk itself
>> has been removed, taking up a slot and making life miserable. :)
>
> I have never experienced this in all the years working with Linux.
Well, I am surprised. Certainly, on non-hotplug hardware the behaviour
of a Linux block device driver is to keep the "device" around and report
appropriate errors.
> Either you haven't un-mounted the device correctly (that is checked
> the return status byte if in a script), or the OS release you refer to
> is/was buggy,
On the other hand, it seems we are talking about different things here.
Yes, if a driver that supports hotplug, with hardware that supports
hotplug, fails to remove the software "device" after the hardware is
gone it has a bug.
[...]
>> (Also, lower layers such as LVM, software RAID, etc, might not flush
>> their data during the unmount process.)
>
> Yep every driver should - otherwise they are badly designed and
> implemented.
I don't think you quite follow: if you unmount a filesystem in an LV,
but keep the PV active, LVM can quite reasonably keep metadata active
and in memory.
You have to deactivate the PV for that to change, which is the
equivalent LVM operation to unmount for a filesystem.
Software RAID behaves in a similar fashion.
[...]
> Yes but that is my point! - This is all part of the kernel drivers
> responsibility - read all about this in the source code... and the
> kernel internals. Hence, there is no need to portray "the overside"
> of hot swapping as problematic - you put it.
Sorry, I don't follow you. I don't recall, and can't find in my text, a
reference to "the overside" of hot swapping.
Can you clarify what you were responding to there?
>>> On the hardware side, the PSU socket must ensure that power is
>>> presented to the drive before logic is connected (ground first). This
>>> is why the +12v, +5v and GND pins are usually extended about 8mm
>>> before the rest of the pins are connected.
>>
>> FWIW, SATA devices are hot-swap and the are ... a little less than
>> 8mm of coverage for those connections. Just sayin'
>
> SATA I, II and forthcoming III specifications originally covered hot-
> swapping. So it would be expected at the hardware level.
My point was that there is not an 8mm long electrical connector on a
SATA cable, or device. Nothing more than that.
Regards,
Daniel
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
