Re: Is IDE to CF viable to archive ?

On 29 Lis, 08:32, problems@gmail wrote:
> I'm told by an 'IDE to CF' user that he can hot-plug
> data from one PC to another, instead of using a floppy.
> Is this OK ?
>
hot-plugging a CF card on a native IDE bus doesn't work.

> What types of flash-cards are commonly available
> that can store 128MB or more ?
>
Any flash card format nowadays on the market
(SD/MMC/XD/MS/CF/USB sticks).

Note that some formats have sub-formats,
older readers are not compatible with latest/largest drives.
A typical boundary is 2GB, and that's not only at the
File System level (FAT16 vs. FAT32). Note that SDHC
cards don't work in SD readers, there are several revisions
of the SD interface with different transfer rates (a backwards
compatible common denominator usually works here).
http://en.wikipedia.org/wiki/Secure_Digital_card
http://en.wikipedia.org/wiki/MultiMediaCard

> Or is IDE to USB [for old boxes without a USB],
> more viable *- with USB memory ?
>
That sounds a tad better. You mean a CF->IDE and IDE->USB, right?
That *might* work, provided that you first hot-plug the USB port,
only then the CF card in the IDE converter.

Imagine that you make your native IDE devices physically hot-
pluggable.
You attach an IDE removable harddisk drawer, or a passive IDE->CF
adapter,
to the physical IDE channel going from your PC's south bridge.
That IDE channel has no signals (wires, pins in the connector,
support in the HBA port) to indicate a hot-swap to the host PC.
The host OS is not prepared to see a device vanish or appear
on an IDE bus - XP sees IDE devices as "permanent drives"
and doesn't even offer the possibility to gracefully "remove"
(unmount, really) the disk volume from the explorer
(via the drive's context menu).

The normal way that IDE works is that
1) the drives get detected by the BIOS. Only once on startup.
2) the OS can use BIOS services to check the drives, or it can probe
the busses on its own via its native low-level IDE driver
(again just once on startup)
3) runtime operation. It's not expected that a previously detected
IDE device (since last boot) would suddenly vanish - that would
likely cause lost data in some write-back buffers. Equally,
it's not expected that a new IDE device would appear out of
nowhere.
If you actually plug an IDE drive to a free physical IDE channel at
runtime,
nothing happens - no software is looking for the new device, noone
polls
that channel, noone gets to know.

The right way to hot-plug a CF card is to use a USB-based reader.
Those readers likely use the "linear" CF access mode
(as opposed to IDE emulation), and in this mode, the CF interface
does support hot-plugging. Thus, such USB CF readers do support
hot-plugging at the CF interface (in the CF slot), without hot-
plugging
the "back end" USB interface.

To the OS, the USB reader ports appear as distinct USB Mass Storage
class devices, explicitly announced as removable. The OS is prepared
for hot-plugs on such devices, offering options such as "remove" and
"eject"
on the corresponding volumes. The aforementioned write-back buffering
issues are somehow handled within the OS - either by disabling write-
back
buffering, or by a disk cache flush hooked up to the "remove" command.
I.e., the user is still required to explicitly "unmount" these hot-
swappable
devices, before he can physically pull the card out of the dongle.

As mentioned before, you can hot-plug physical IDE drives to any
computer, as long as you use an IDE->USB converter and you really
do the hot-plug at the USB interface level. In some cases, Windows
still see such a USB-attached hard drive as a permanently connected
hard disk, and don't offer the "remove" option on the context menu
- but you still have the option to "stop" the whole USB device.

It actually seems like the "permanent/removable media" flag is at the
IDE registers level already, and passed through by the USB/IDE
converter.
It makes some sense - e.g. ATAPI CD-ROM / ZIP drives might use this
flag.

Frank Rysanek

In comp.os.linux.hardware wrote:
> Imagine that you make your native IDE devices physically hot-
> pluggable.
> You attach an IDE removable harddisk drawer, or a passive IDE->CF
> adapter,
> to the physical IDE channel going from your PC's south bridge.
> That IDE channel has no signals (wires, pins in the connector,
> support in the HBA port) to indicate a hot-swap to the host PC.
> The host OS is not prepared to see a device vanish or appear
> on an IDE bus - XP sees IDE devices as "permanent drives"
> and doesn't even offer the possibility to gracefully "remove"
> (unmount, really) the disk volume from the explorer
> (via the drive's context menu).

I can't comment for Windows, but last time I looked (maybe 2005) Linux had
the beginnings of ATA hotplug support. Prerequisites:

Hotplug hardware. This needs to know to power up/down the drive and ATA bus
signals in the right order. Cheap caddies won't do, high-ish end RAID trays
might. Cheap IDE-CompactFlash adaptors probably won't do this, but it
wouldn't be too expensive to make one that did.

One device per bus. Removing a master from underneath a slave or vice versa
could be messy, so you'd need a dedicated IDE bus for each device.

A Linux driver that supports on-the-fly adding and removal of devices. This
wasn't finished when I checked, but possibly SATA has brought this forward.

A means to manually tell the driver that you're removing or replacing a
tray. As you say, ATA has no indication of (de)insertion events, but it's
possible to tell the driver explicitly what you have done.


Most of the work in Linux (and presumably other OSs) has had to be done for
SATA anyway, so support may be there (but perhaps not too well tested).

But these days, I can't see why anyone would bother. To buy a PATA hotswap
enclosure is most likely going to cost more than an equivalent SATA drive,
and SATA explicitly supports hotswap. So, just as the Right Answer for
CompactFlash is to use USB, the Right Answer for hard drives is to use SATA.

Theo

On 8 Pro, 13:27, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
> >
> > The host OS is not prepared to see a device vanish or appear
>
> I can't comment for Windows, but last time I looked (maybe 2005) Linux had
> the beginnings of ATA hotplug support.
[...]
> Most of the work in Linux (and presumably other OSs) has had to be done for
> SATA anyway, so support may be there (but perhaps not too well tested).
>
> But these days, I can't see why anyone would bother.
>
Exactly :-)

I remember AXUS used to have a PATA-to-SATA converter module in every
PATA disk tray in their PATA RAID models (Demon series) some
four years ago. That way, you had IDE/PATA drives, but the hot-swap
was actually arranged using a SATA connector and SATA HBA :-)
A very popular chip in this role is the Marvell 88SX6041/6081,
so those "legacy" SATA-only chips used to have some hot-swap
support back then, and the Accusys/Areca RAID firmware can work
with that very well. I recall my amazement at the swiftness of hotswap
responses in SATA enclosures, compared to GEM318-based SCA SCSI.

Since then, there are AHCI-class SATA HBA's and SAS HBA's - both
standards IMO support hot-swap much better up to the OS driver level.

As for native PATA/IDE HBA's, obviously there are the soft RAID's by
Promise,
and HW PATA RAID's by 3ware, both of which could handle hot-swaps
of PATA drives. So the hardware capable of that clearly exists.
And it works even with the cheapest PATA drawers by ViPower
and the like - maybe the RAID firmware just polls the PATA channels
regularly to check for drive presence/absence.
You're right - one drive per each PATA channel has always been
the golden rule of PATA RAID setups :-)

The Intel ICH*R SATA HBA's are also capable of handling hot-swap
actions,
at least in the "RAID" mode (with a dedicated HW-specific driver).
In terms of admin comfort, an Intel ICH*R with an Adaptec option ROM
(HostRAID)
is on par with Promise soft-RAID's...

Frank Rysanek