Hi All,
I apologise that this question is coming from a user, but I believe the
readers here are the only ones I can trust for a reliable answer, I have
searched the Internet for many days during the last month for all
available information, and due to the nature of the problem, I cannot
tell whether any solution I write actually works properly.
The scenario: I have a ViPower hot-swap mobile rack for swapping IDE HDs
on the fly. I am assuming that this device properly disconnects the
hardware and that I am faced with a software problem. Our technical
staff tell me that they have 'tested' hot swapping under RedHat 7.3
(Kernel 2.4.18-3) and it 'works'. In other words, they unmounted,
swapped, and mounted a new disk and didn't observe data loss. I am sure
that they are mistaken that this is a reliable process, as I have read a
great deal about the hdparm program and its -R and -U switches. But
nothing that I can find explains exactly what is going on when hdparm is
called; the man page is dreadfully vague.
I would like to write a utility that works as follows:
To unmount:
unmount partitions
Use hdparm -U to unregister
Auto-remove lines in fstab referring to removable device (to avoid
marnings on bootup check)
To remount:
Use hdparm -R to register the new device
Auto-install lines in fstab relevant to removable device
mount partitions
My question: Given your knowledge of the innards of the kernel, does the
above seem like a sound way to create a useful IDE hot-swap utility? As
the simple unmount/remount strategy _seems_ to work, I am not confident
that just programming this up and trying it will necessarily reveal any
flaws, which is why I seek your advice.
Here are a few other factoids that may be relevant. This utility comes
with Windoze drivers to set up hot-swapping. I installed them and they
worked, but immediately Partition Magic started crashing Windoze
whenever it was run. This behaviour even continued after uninstallation
of the hot-swap drivers. Furthermore, at that point Linux started
producing lines like this in /var/log/messages:
Mar 26 13:35:44 Loris kernel: hdd: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Mar 26 13:35:44 Loris kernel: hdd: dma_intr: error=0x84 {
DriveStatusError BadCRC }
(the above repeated half dozen or so times, then:)
Mar 26 13:35:44 Loris kernel: ide1: reset: success
After that, things work. I am startled that a Windoze driver has left an
effect in the system that is felt by Linux. Everything looks OK in the
bios setup, but I am not an expert and may have missed something.
Again, I apologise for a user posting on a kernel list, but I have done
a lot of work looking for answers and I do believe this is the only
place where solid understanding of the underlying problem is to be found.
Many thanks for any insight.
--
Ron House [email protected]
http://www.sci.usq.edu.au/staff/house
On Wed, 2003-03-26 at 04:41, Ron House wrote:
> The scenario: I have a ViPower hot-swap mobile rack for swapping IDE HDs
> on the fly. I am assuming that this device properly disconnects the
> hardware and that I am faced with a software problem. Our technical
> staff tell me that they have 'tested' hot swapping under RedHat 7.3
> (Kernel 2.4.18-3) and it 'works'. In other words, they unmounted,
> swapped, and mounted a new disk and didn't observe data loss. I am sure
IDE hotswap at drive level is not supported by Linux. It might work ok.
Providing you shut the drive down fully and flush the cache before you
unregister/unplug and replug before registering the new interface
> Here are a few other factoids that may be relevant. This utility comes
> with Windoze drivers to set up hot-swapping. I installed them and they
> worked, but immediately Partition Magic started crashing Windoze
> whenever it was run. This behaviour even continued after uninstallation
> of the hot-swap drivers. Furthermore, at that point Linux started
> producing lines like this in /var/log/messages:
>
> Mar 26 13:35:44 Loris kernel: hdd: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Mar 26 13:35:44 Loris kernel: hdd: dma_intr: error=0x84 {
> DriveStatusError BadCRC }
Looks like it left the drive misprogrammed
Alan
On 26 Mar 2003, Alan Cox wrote:
> IDE hotswap at drive level is not supported by Linux. It might work ok.
> Providing you shut the drive down fully and flush the cache before you
> unregister/unplug and replug before registering the new interface
There was a bunch of discussion of this, possibly on this list, and I
believe that the whole cable has to be unregistered or some such. I've
done it with only one drive on a cable, and it seemed to work. On the
other hand I was only playing.
I've seen some note regarding using ide-floppy for the whole drive instead
of the media, but I have never had the urge to try that.
WARNING: removable and hot swapable bays are not the same, had a client
prove that to herself the hard way.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Alan Cox wrote:
> On Wed, 2003-03-26 at 04:41, Ron House wrote:
>
>>The scenario: I have a ViPower hot-swap mobile rack for swapping IDE HDs
>>on the fly. I am assuming that this device properly disconnects the
>>hardware and that I am faced with a software problem. Our technical
>>staff tell me that they have 'tested' hot swapping under RedHat 7.3
>>(Kernel 2.4.18-3) and it 'works'. In other words, they unmounted,
>>swapped, and mounted a new disk and didn't observe data loss. I am sure
>
>
> IDE hotswap at drive level is not supported by Linux. It might work ok.
> Providing you shut the drive down fully and flush the cache before you
> unregister/unplug and replug before registering the new interface
Thanks Alan. What is needed to do this? Is umounting and then
unregistering with hdparm -U enough to do this, or is something else needed?
--
Ron House [email protected]
http://www.sci.usq.edu.au/staff/house
Bill Davidsen wrote:
> On 26 Mar 2003, Alan Cox wrote:
>
>
>>IDE hotswap at drive level is not supported by Linux. It might work ok.
>>Providing you shut the drive down fully and flush the cache before you
>>unregister/unplug and replug before registering the new interface
>
>
> There was a bunch of discussion of this, possibly on this list, and I
> believe that the whole cable has to be unregistered or some such. I've
> done it with only one drive on a cable, and it seemed to work. On the
> other hand I was only playing.
Thanks Bill, I have read everything I can find in the archives, but am
still confused as to what exactly is going on. My current understanding is:
On boot, Linux examines the ide drive for physical parameters. Then,
mounting causes filesystem details to be loaded.
Now clearly, unmounting should undo mounting (or does the kernel keep
something even here in memory for 'efficiency?). So is hdparm -U enough
to undo the loading of physical parameters, and will hdparm -R reload them?
> I've seen some note regarding using ide-floppy for the whole drive instead
> of the media, but I have never had the urge to try that.
>
> WARNING: removable and hot swapable bays are not the same, had a client
> prove that to herself the hard way.
This device is claimed to be 'hot-swappable'. It has circuitry on board,
which I presume does the necessary isolation and power down as claimed
in the blurb.
As an aside, I am puzzled by statements that Linux `doesn't support'
this. As far as I can see (and I acknowledge my relative ignorance,
which is why I have appealed for help here), whatever is done at boot
time can be done again later if conditions change, and it should be just
a matter of my ascertaining exactly what must be done to achieve this.
Or have I missed something very important (highly possible!)?
--
Ron House [email protected]
http://www.sci.usq.edu.au/staff/house
On Thu, 2003-03-27 at 22:21, Ron House wrote:
> Bill Davidsen wrote:
> > On 26 Mar 2003, Alan Cox wrote:
> >
> >
> >>IDE hotswap at drive level is not supported by Linux. It might work ok.
It might be better to say not supported fully, or support not complete.
Most chipsets and their linux drivers have the ability to tristate-off
the IDE bus, making it work safely on the electrical level. Switching
off the power to the drive has to be provided by the swap bay in
question. I can get that for $17 CDN. But...
> >>Providing you shut the drive down fully and flush the cache before you
> >>unregister/unplug and replug before registering the new interface
> >
This is another piece of the puzzle. The kernel buffer-cache can be
flushed by a simple sync command. I've only seen the IDE write cache
flushed by the kernel on shutdown. So the code is kinda there, but
needs to have a command to initiate it like sync does for the kernel.
Unfinished...
> >
> > There was a bunch of discussion of this, possibly on this list, and I
> > believe that the whole cable has to be unregistered or some such. I've
> > done it with only one drive on a cable, and it seemed to work. On the
> > other hand I was only playing.
Yes, the whole cable. You don't put more than one IDE device on one
cable, do you? IDE TCQ may help performance in those cases (how will
IDE bus to disconnect/*reconnect*?) But hot swap will always affect both
cables.
>
> Thanks Bill, I have read everything I can find in the archives, but am
> still confused as to what exactly is going on. My current understanding is:
>
> On boot, Linux examines the ide drive for physical parameters. Then,
> mounting causes filesystem details to be loaded.
See below...
>
> Now clearly, unmounting should undo mounting (or does the kernel keep
> something even here in memory for 'efficiency?). So is hdparm -U enough
> to undo the loading of physical parameters, and will hdparm -R reload them?
>
> > I've seen some note regarding using ide-floppy for the whole drive instead
> > of the media, but I have never had the urge to try that.
> >
> > WARNING: removable and hot swapable bays are not the same, had a client
> > prove that to herself the hard way.
>
> This device is claimed to be 'hot-swappable'. It has circuitry on board,
> which I presume does the necessary isolation and power down as claimed
> in the blurb.
>
> As an aside, I am puzzled by statements that Linux `doesn't support'
> this. As far as I can see (and I acknowledge my relative ignorance,
> which is why I have appealed for help here), whatever is done at boot
> time can be done again later if conditions change, and it should be just
> a matter of my ascertaining exactly what must be done to achieve this.
> Or have I missed something very important (highly possible!)?
What can be done at boot... correct. However, the BIOS does part of the
BOOT init, the linux kerenel IDE driver does some more. So changing the
drive without rebooting through BIOS can be a problem. The PIO modes
are the issue here. Perhaps a script can do hdparm -X somehow, but
nobody is certain if it will be reliable, because who knows what the
bios does. With LinuxBIOS there is hope though.
IMHO the ide driver is a real mess. statically allocated structures,
because the kernel command line parameters have to be read early because
they're so wierd, no wonder the hdparm -U / -R stuff is busted. It
should take the PCI ID of the interface, not the io ports. Fixing this
is on my hit list, in about a month.
Regards,
Jeremy
--
Jeremy Jackson <[email protected]>
On Fri, 2003-03-28 at 14:04, Jeremy Jackson wrote:
> It might be better to say not supported fully, or support not complete.
> Most chipsets and their linux drivers have the ability to tristate-off
> the IDE bus, making it work safely on the electrical level. Switching
> off the power to the drive has to be provided by the swap bay in
> question. I can get that for $17 CDN. But...
Hardly "most", I think its two
> This is another piece of the puzzle. The kernel buffer-cache can be
> flushed by a simple sync command. I've only seen the IDE write cache
And on umount by 2.5, or always on 2.4 as well if the device is marked
removable
> What can be done at boot... correct. However, the BIOS does part of the
> BOOT init, the linux kerenel IDE driver does some more. So changing the
> drive without rebooting through BIOS can be a problem. The PIO modes
> are the issue here. Perhaps a script can do hdparm -X somehow, but
> nobody is certain if it will be reliable, because who knows what the
> bios does. With LinuxBIOS there is hope though.
Not really the PIO modes. In fact the PIO modes are generally just fine.
The problems are mostly at the DMA and UDMA end of things where there
is complex setup or interactions involved.
> IMHO the ide driver is a real mess. statically allocated structures,
You bet.
> because the kernel command line parameters have to be read early because
> they're so wierd, no wonder the hdparm -U / -R stuff is busted. It
> should take the PCI ID of the interface, not the io ports. Fixing this
> is on my hit list, in about a month.
2.7 at the earliest, and only if there is a general buy in about such a
change to the init handling. Similarly the big issues with hdparm -U and
-R are the same as with hotplug races, and will take a lot more than
quick hacks to fix.
Alan
On Fri, 2003-03-28 at 03:03, Ron House wrote:
> Thanks Alan. What is needed to do this? Is umounting and then
> unregistering with hdparm -U enough to do this, or is something else needed?
If the hardware can do it then most of the time yes. Just very very
occasionally it might blow up in your face, but thats stuff which is
going to take a lot of fixing and wont get fixed for 2.4 I fear
On 28 Mar 2003, Jeremy Jackson wrote:
> > As an aside, I am puzzled by statements that Linux `doesn't support'
> > this. As far as I can see (and I acknowledge my relative ignorance,
> > which is why I have appealed for help here), whatever is done at boot
Nope, there are BIOS INT19 hooks that have some voodoo.
Until the driver can open and read the BIOS on the HBA, no can do.
> > time can be done again later if conditions change, and it should be just
> > a matter of my ascertaining exactly what must be done to achieve this.
> > Or have I missed something very important (highly possible!)?
>
> What can be done at boot... correct. However, the BIOS does part of the
> BOOT init, the linux kerenel IDE driver does some more. So changing the
> drive without rebooting through BIOS can be a problem. The PIO modes
> are the issue here. Perhaps a script can do hdparm -X somehow, but
> nobody is certain if it will be reliable, because who knows what the
> bios does. With LinuxBIOS there is hope though.
LOL, LinuxBIOS can not even get POST on execute diagnostics correct.
It violently nukes the state machine requirements of a 31 seconds.
This is another war and I really do not give a damn to fight, when nobody
listens or bothers to read the freaking spec. Anybody got a copy of the
Phoenix BIOS book to see how the old hats did it?
> IMHO the ide driver is a real mess. statically allocated structures,
> because the kernel command line parameters have to be read early because
Sure kill all the legacy stuff and split the driver.
If you are wanking so hard on the setup, take and export all the setup to
their respective modules (ie hba's). As for the static structs, I pushed
to have dynamic major/minor allocations but got dive bombed with a flock
of sea gulls.
> they're so wierd, no wonder the hdparm -U / -R stuff is busted. It
> should take the PCI ID of the interface, not the io ports. Fixing this
> is on my hit list, in about a month.
I just love how everyone thinks it is so easy, how I made such a freaking
mess of the driver. Well you all can dork with it and I will wander off
and intergrate the chipset cores. The only reason it is even close to
becoming clean is because the core transport layer for the state machine
was ripped appart and started from the ground up.
Hell, just ask and I will turn the whole transport into as SCSI wrapper
and we can root wad the directory.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
May I thank all of you who have taken time and been so kind as to help
out with my question. I'll try to put concrete something together, and
perhaps ask for any specific comment at that time.
Just one general comment, though. I believe it would be a very big coup
for Linux if this feature (hot-swap IDE) were built into Linux properly.
These big HDs are getting cheap, and the ability to back-up entire
systems, send truly huge image and sound files to colleagues, etc., make
this a really high-potential medium. A concrete *feature* like this
would really speak to less knowledgeable users than some of the more
technical developments, vital though they are.
Anyway, thank you all and thanks also for your dedicated and selfless
work for the rest of us!
--
Ron House [email protected]
http://www.sci.usq.edu.au/staff/house
> Just one general comment, though. I believe it would be a very big coup
> for Linux if this feature (hot-swap IDE) were built into Linux properly.
> These big HDs are getting cheap, and the ability to back-up entire
> systems, send truly huge image and sound files to colleagues, etc., make
> this a really high-potential medium. A concrete *feature* like this
> would really speak to less knowledgeable users than some of the more
> technical developments, vital though they are.
I agree.
Something that occurs to me - if a machine has non hot-swap capable
IDE hardware, but has suspend to RAM functionality, presumably it is
OK from an electronic viewpoint to swap disks? What about PCI hot
swap? Presumably we can remove a non hot-swap IDE controller
completely, and re-install it with different drives connected?
In other words, perhaps IDE hot swap capable equipment is not
completely a pre-requisite to make use of IDE hot swap from the kernel
point of view.
John.
> > Something that occurs to me - if a machine has non hot-swap capable
> > IDE hardware, but has suspend to RAM functionality, presumably it is
> > OK from an electronic viewpoint to swap disks? What about PCI hot
> > swap? Presumably we can remove a non hot-swap IDE controller
> > completely, and re-install it with different drives connected?
>
> It is but Linux doesn't support it
Not yet :-)
Seriously, I thought both were under active development - is this a
2.7, or 2.9 timescale thing?
John.
On Mon, 2003-03-31 at 10:30, John Bradford wrote:
> Something that occurs to me - if a machine has non hot-swap capable
> IDE hardware, but has suspend to RAM functionality, presumably it is
> OK from an electronic viewpoint to swap disks? What about PCI hot
> swap? Presumably we can remove a non hot-swap IDE controller
> completely, and re-install it with different drives connected?
It is but Linux doesn't support it
On Mon, 2003-03-31 at 12:21, John Bradford wrote:
> > > Something that occurs to me - if a machine has non hot-swap capable
> > > IDE hardware, but has suspend to RAM functionality, presumably it is
> > > OK from an electronic viewpoint to swap disks? What about PCI hot
> > > swap? Presumably we can remove a non hot-swap IDE controller
> > > completely, and re-install it with different drives connected?
> >
> > It is but Linux doesn't support it
>
> Not yet :-)
>
> Seriously, I thought both were under active development - is this a
> 2.7, or 2.9 timescale thing?
Probably yes
On 28 Mar 2003, Jeremy Jackson wrote:
> On Thu, 2003-03-27 at 22:21, Ron House wrote:
> > Bill Davidsen wrote:
> > > There was a bunch of discussion of this, possibly on this list, and I
> > > believe that the whole cable has to be unregistered or some such. I've
> > > done it with only one drive on a cable, and it seemed to work. On the
> > > other hand I was only playing.
>
> Yes, the whole cable. You don't put more than one IDE device on one
> cable, do you? IDE TCQ may help performance in those cases (how will
> IDE bus to disconnect/*reconnect*?) But hot swap will always affect both
> cables.
Boy I hope that's a typo... I hope you meant both devices on a cable and
not really both cables on a controller.
And as for more than one device on a cable, I wouldn't expect hot swap to
work, but sure I have have a ZIP drive on a cable with a 2nd CD-ROM drive,
I use ZIP about as often as my cat farts Channel No5, I don't tie up a
cable for something which may go a year between uses. Don't use the
standby 16x CD more than a few times a year, either.
The removable drive I did get working was on its own old controller. And
it worked fine, I copied a fair number of old 420MB drives to CD after
they came out of machines which might have had something useful. Just in
case I ever think of something worth a treasure hunt. The drives were
wiped and used for a software RAID proof of concept project.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, 2003-03-31 at 14:14, Bill Davidsen wrote:
> > IDE bus to disconnect/*reconnect*?) But hot swap will always affect both
> > cables.
>
> Boy I hope that's a typo... I hope you meant both devices on a cable and
> not really both cables on a controller.
Yep, sorry. The IDE controller must tri-state off an entire cable...
both devices. I guess you could have 2 devices, and swap one but leave
the other, you just have to halt all IO durring the swap, perhaps reset
both devices when the cable is switched back on.
Interesting to note, Intel's PIIX (forget what version) had a feature
that would split the primary cable (from the OS point of view - think
dos here) so the master was on the primary cable, and the slave was on
the secondary cable. each device (ie swap bay in a laptop) could be
tristated separately. of course you loose the secondary channel.
--
Jeremy Jackson <[email protected]>