Bill Freeman <f@ke1g.mv.com>,
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>
BF> 1. The drive in question is an ATAPI Zip 250MB drive.
BF>
BF> 2. I've only used it with 100MB media (cartridges, but 250MB
BF> should yield to similar efforts.
BF>
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>
BF> 4. The drive is not accessible using the pd module, but the
BF> pf module understands the hardware just fine.
BF>
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>
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>
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>
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>
BF> B * (s - 1 + (S * (h + (H * c))))
BF>
BF> or, in my case:
BF>
BF> 512 * (1 - 1 + (32 * (1 + (64 * 0)))) == 16384
BF>
BF> Use q to exit fdisk.
BF>
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>
BF> losetup -o 16384 /dev/loop0 /dev/pf0
BF> mount -t auto /dev/loop0 /mnt/mnt
BF>
BF> Read and write the drive as any VFAT filesystem.
BF>
BF> 7. These may not be completely necessary, but when finished, I
BF> did the following:
BF>
BF> umount /dev/loop0
BF> losetup -d /dev/loop0
BF> eject /dev/pf0
BF>
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>
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>
BF> Bill
BF>
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>
BF> -- To unsubscribe, send mail to: linux-parport-request@torque.net --
BF> -- with the single word "unsubscribe" in the body of the message. --
BF>
BF>
\/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- 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