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

From: Robert Heller (
Date: Tue Apr 29 2003 - 18:51:43 EDT

  • Next message: Tim Waugh: "Re: [PARPORT] libieee1284-0.2.7 documentation?"

      Bill Freeman <>,
      In a message on Tue, 29 Apr 2003 15:51:06 -0400 (EDT), wrote :

    BF> The easy way to do this is with the -o option to losetup, as
    BF> several people pointed out. I'm summarizing my experiences below for
    BF> the archive, in case it turns out to be useful to someone in the
    BF> future. Thanks to all who responded.
    BF> 1. The drive in question is an ATAPI Zip 250MB drive.
    BF> 2. I've only used it with 100MB media (cartridges, but 250MB
    BF> should yield to similar efforts.
    BF> 3. The module stack that I'm using, under a recent 2.4 Linux
    BF> kernel (that which ships on the original release of RedHat 9.0) is:
    BF> pf -> on26 -> paride. Obviously, you replace on26 with the protocol
    BF> driver suitable to your adapter. The paride documentation files in
    BF> the kernel source are most helpful.
    BF> 4. The drive is not accessible using the pd module, but the
    BF> pf module understands the hardware just fine.
    BF> 5. Now it's time to figure out how far into /dev/pf0 the
    BF> partition begins. Run 'fdisk /dev/pf0'. Use the x command to enter
    BF> "expert" mode. Use the p command to print the partition table. Yes,
    BF> there is a p command to print the partition table in non-expert mode,
    BF> but it doesn't give you the same collection of information.
    BF> The header printed tells you how many sectors, heads, and
    BF> cylinders you have on the media, 32, 64, and 95 for the 100MB media.
    BF> The partition line tells you, among other things, which sector, using
    BF> which head, on which cylinder, the partition begins. In the case of
    BF> the 100MB media it was sector 1, head 1, cylinder 0.
    BF> At this point you must remember that disk blocks here are 512
    BF> bytes, no matter than many of your Linux tools report in 1k "blocks".
    BF> (I can remember disks with different physical block sizes, but I've
    BF> never run across them in the PC world. Probably fdisk would tell me
    BF> about that too.) You must also remember that while cylinder and head
    BF> numbering starts with 0, sector numbering starts with 1.
    BF> Then, if H is the total number of heads, h is the head on which
    BF> the partition starts, S is the total number of sectors, s is the sector
    BF> at which the partition starts, c is the cylinder on which the partition
    BF> starts, and B is the number of bytes per block, then the necessary
    BF> offset is:
    BF> B * (s - 1 + (S * (h + (H * c))))
    BF> or, in my case:
    BF> 512 * (1 - 1 + (32 * (1 + (64 * 0)))) == 16384
    BF> Use q to exit fdisk.
    BF> 6. Set up a loop back device to let you read and write pf0
    BF> with the offset calculated in item 5, above, and mount the loop back
    BF> device:
    BF> losetup -o 16384 /dev/loop0 /dev/pf0
    BF> mount -t auto /dev/loop0 /mnt/mnt
    BF> Read and write the drive as any VFAT filesystem.
    BF> 7. These may not be completely necessary, but when finished, I
    BF> did the following:
    BF> umount /dev/loop0
    BF> losetup -d /dev/loop0
    BF> eject /dev/pf0
    BF> If you want, you can remove the modules at this point
    BF> (assuming that you dynamically loaded them, rather than building them
    BF> into your kernel).
    BF> 8. I've pretty much decided that this is easy enough that I'm
    BF> not going to sign up to "upgrade" the pf driver to handle partitions.

    You would not be able to anyway -- the pf device does not have the
    minor number space to support partitions. What *really* should be done
    is fix paride and/or the lower-level driver (on26) to treat Zip drives
    as regular disks using the pd driver (eg /dev/pdXn) not as floppy
    drives (/dev/pfN). Actually, *I'm* not convinced that there really is a
    reason for 'IDE Floppy Drives', unless there is something totally brain
    dead about the IDE interface spec. (One can deal with non-partitioned
    hard drives if one really wants to by using the unnumbered devs
    (/dev/pda or /dev/hda or /dev/sda) In any case, it makes me very glad
    that I have managed to mostly avoid the whole IDE mess in the first
    place. The *only* IDE device I have to deal with is the hard drive in
    my laptop -- ALL of the rest of my computers are 100% SCSI (Hard
    drives, CD-ROM, tape drive, Zip drive, ORB drive, and Scanner). These
    sorts of sillienesses don't happen in the SCSI world -- *my* Zip drive
    is properly handled as a partitioned device (/dev/sdcN). Note: the
    parallel port and USB Zip drives use the SCSI interface (/dev/sdXn).

    BF> Bill
    BF> I originally wrote:
    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> > Is there something short of reworking the pf driver to support
    BF> > partitioning that will get me around this?
    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 : Tue Apr 29 2003 - 18:50:28 EDT