Re: [PARPORT] partitions on Zip disk, ATAPI Zip drive via pf, on26, paride

From: Robert Heller (
Date: Fri Apr 25 2003 - 22:17:51 EDT

  • Next message: Bill Freeman: "[PARPORT] partitions on Zip disk, ATAPI Zip drive via pf, on26, paride"

      Bill Freeman <>,
      In a message on Fri, 25 Apr 2003 15:09:03 -0400 (EDT), wrote :

    BF> Robert Heller writes:
    BF> >
    BF> >
    BF> > In message <>, Bill Freeman writes:
    BF> > > I have an external prallel port generic IDE drive box that
    BF> > >works with on26. Using a normal IDE disk and pd things are just fine.
    BF> > >
    BF> > > I'd like to use it with an ATAPI Zip drive. Using pf, fdisk
    BF> > >can see it just fine, and I can, for example, eject the disk with
    BF> > >eject.
    BF> > >
    BF> > > But, since pf was apparently written with non-partitioned
    BF> > >disks (LS-120, CDs) in mind. Zip disks, however, are partitioned.
    BF> >
    BF> > *Normal* (internal) IDE Zip drives, show up like 'regular' IDE disks --
    BF> > /dev/hdX, which can be partitioned (or not). Same is true of SCSI Zip
    BF> > drives, both as true SCSI Zip drives (yes, these do exist) and as
    BF> > parallel port types (which have a built-in parallel port SCSI
    BF> > interface) -- they show up as 'regular' SCSI disks, eg /dev/sdX.
    BF> > Shouldn't the IDE (ATAPI) Zip drive connected via your parallel-port
    BF> > IDE controller also show up as just another IDE disk?
    BF> By this do you mean that when the pf module recognizes the
    BF> drive that it should then show up as hdX? I'll have to look closer,

    No, if you attach your IDE Zip drive to a desktop computer's internal
    IDE bus it shows up as /dev/hdX.

    BF> but I don't think so. (The box is home, I'm at work, so I won't get a
    BF> chance to try for a while). Certainly, when I stick an IDE hard drive
    BF> in this box and use the pd module, it shows up as pda\d*, not, for
    BF> example, hde\d*. As a point of interest, fdisk labels the partition
    BF> pf0p1, which, of course, is not an existing node.

    If an IDE hard drive shows up as /dev/pda*, then *I* would think that
    the Zip drive should also show up as /dev/pda*. Unless the /dev/p*
    devices (and corresponding drivers) are somehow confused about just
    what the Zip drive is. I've only really dealt with SCSI devices --
    things make much better sense with SCSI. The SCSI spec. understands
    about 'removable media hard drives'. IDE is mostly a hack that has
    grown out of the old hard-card 'hack'.

    BF> > > Is there something short of reworking the pf driver to support
    BF> > >partitioning that will get me around this?
    BF> >
    BF> > Can you see the Zip drive as a 'regular' IDE disk via your parallel
    BF> > port IDE interface (I'm guessing /dev/pdXn)? If so, that is your
    BF> > solution.
    BF> No. The pd module doesn't recognize the drive. pf does and
    BF> correctly reports the identity string, after which /dev/pf0 is a working
    BF> argument for fdisk and eject. mount claims not to recognize the file
    BF> system, since, of course, the master record with the partition table
    BF> is not a valid superblock, etc.

    OK, it looks like the /dev/p[df] drivers are 'brain dead' (from my point
    of view) or at least it is an inherent problem with the parallel-port
    IDE driver logic, and may in fact be an inherent problem with IDE over
    parallel port in general. Unless there is a way to coerce the driver to
    consider the Zip drive as a hard disk (some sort of module load
    parameter settings in /etc/modules.conf or something). If you can
    somehow *force* the paride driver to configure the Zip drive as if it
    was a hard drive and NOT as a floppy disk, you might get your
    partitioning. You may lose the 'eject' function (but you probably can
    live with this).

    I just looked at the device numbers for /dev/pf* and /dev/pd*. The
    /dev/pd* devices have minor numbers just like to /dev/hd* and
    /dev/dev/sd*: minor numbers are set up so the low-order 4 bits are the
    partition number and the upper 4 bits are the drive number: /dev/pda is
    45,0 (the whole of device 0 (a)), /dev/pda1 is 45,1 (partition #1 of device 0
    (a)), /dev/pdb is 45,16 (the whole of device 1 (b)), etc. The /dev/pf's
    are /dev/pf0 is 47,0; /dev/pf1 is 47,1, etc.

    The only thoughts I have would be either to patch the /dev/p* drivers
    (or use some sort of parameter magic in /etc/modules.conf or with
    modprobe) to make it think of the Zip drive as a 'removable media hard
    drive' (and use the /dev/pdXn devices) and not a 'big IDE floppy drive'
    (/dev/pfN). Or in fact just toss the IDE Zip drive + parallel port IDE
    box and just get a proper parallel port Zip drive (really a SCSI Zip
    drive with integrated parallel port SCSI controller) and use the
    parallel-port SCSI controller (ppa.o). With this driver a parallel
    port (SCSI) Zip drive will show up as /dev/sdXn (X = a for first SCSI
    disk, n = partition number (1-15) or blank for the whole disk), giving
    all of the proper options for partitioning.

    BF> > Note: you don't *have* to partition Zip carts, although it is a normal
    BF> > thing to do.
    BF> True, I wouldn't have to partition a Zip disk for internal use,
    BF> but when someone hands me a Zip disk as a sneaker-net transfer, and her
    BF> system (not Linux) uses partitioning, I need to deal with it. (Not that
    BF> there aren't workarounds. Use the Zip drive on the desktop and the
    BF> ethernet, for example. But it would be nice to be able to keep this
    BF> box in the trunk of the car for use with the laptop.)
    BF> Bill
    BF> -- To unsubscribe, send mail to: --
    BF> -- with the single word "unsubscribe" in the body of the message. --

    Robert Heller ||InterNet: || /\FidoNet: 1:321/153


    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Fri Apr 25 2003 - 22:13:30 EDT