The FAQ speaks the truth, from a certain point of view. ZIP drives are fully supported by the kernel, if you have a SCSI ZIP drive, and you like using FAT or you know how to write a disktab entry and you know how to add mount points for removable devices to your system.

We'll start with the worst case scenarios first.

Did you buy the parallel port version, or plug a SCSI ZIP into your parallel port, or (horrors) plug either type of external ZIP into an old serial port?

Especially on AT cases with many unlabelled DB-25 ports on the back panel, it is frighteningly easy to accidentally plug an external ZIP into the wrong port. If this has happened to you, pray that your ZIP has not been damaged by it. Iomega does offer a "SCSI+parallel" ZIP drive which theoretically can detect what port it is plugged into and react appropriately, but these drives are regarded with wary suspicion by the hardware literate.

If you have a parallel port ZIP drive, NetBSD currently has no formal support for it. I have heard that a port of the Linux parallel ZIP driver exists out on the net somewhere; use at your own risk.

atapibus1 drive 1: <IOMEGA  ZIP 100       ATAPI, , 23.D>
	type 0 direct removable not configured

It means you saved money buying a $99 ATAPI internal ZIP, but your kernel does not have the patches to support it. Here's what you do:

1. Try "ls /usr/src/sys/arch/i386/conf". If this directory does not exist on your system, you are almost certainly running the GENERIC kernel. If you know you are running the GENERIC kernel, then there is a pre-built version containing the ATAPI/IDE patches on the NetBSD FTP site for you to use:

cd /
ftp ftp://ftp.netbsd.org/pub/NetBSD/arch/i386/ide-1.3.2/netbsd-GENERIC.gz
gunzip netbsd-GENERIC.gz
mv netbsd netbsd.old
mv netbsd-GENERIC netbsd
reboot

... and skip down to the next question.

2. If you do have the kernel source directory, and you are running a kernel you built yourself, then you'll want to patch your existing sources and build a new kernel:

cd /usr/src
ftp ftp://ftp.netbsd.org/pub/NetBSD/arch/i386/ide-1.3.2/1.3.2-ide.tgz
ftp ftp://ftp.netbsd.org/pub/NetBSD/arch/i386/ide-1.3.2/README
tar xzvf 1.3.2-ide.tgz	      # this stuff is described in the README
patch -p -E < 1.3.2-ide.diff
cd sys/arch/i386/conf

2a. Edit your kernel's config file. If you modified GENERIC, then it may not have been patched correctly by 'patch'. Note that the README on the FTP site is missing a vital edit, the 'sd' line. The safest thing to do is add all these lines:

pciide* at pci ? dev ? function ?
wdc*    at isapnp?  
wdc*    at pcmcia? function ?
wd*     at pciide? channel ? drive ?
atapibus* at pciide? channel ?
sd*     at atapibus? drive ?            # ATAPI disk drives

And change these two lines:

wd*     at wdc? drive ?                 # the drives themselves
atapibus* at wdc?

to:

wd*   at wdc? channel ? drive ?
atapibus* at wdc? channel ?

2b. Now re-config and rebuild. To be safe, rebuild the whole thing:

rm -r ../compile/MYKERNEL
config MYKERNEL
cd ../compile/MYKERNEL
make depend && make
mv netbsd /netbsd.new
cd /
mv netbsd netbsd.old
mv netbsd.new netbsd
reboot

sd0 at atapibus0 drive 1: <IOMEGA  ZIP 100       ATAPI, , 23.D>
	type 0 direct removable

ATAPI should have been called "SID", for SCSI In Disguise. Basically what is happening with ATAPI CD-ROM and ZIP drives is that the normal SCSI interface is used pretty much intact, except that the IDE interface is used to send the commands and data back and forth. Quite the brilliant kludge, really.

Either way, it means your ATAPI ZIP drive is now ready to be used. Onward!

It means your ZIP drive is empty, or the disk isn't inserted all the way.

This actually happened to me once with a 10-pack of colored ZIPs. It means that you've found a totally unformatted ZIP disk -- a manufacturing error at Iomega or else you just bought El Cheapo media for your ZIP. You'll probably need to use your SCSI or PC BIOS to hard-format the ZIP drive with that disk in it. I went looking for a hard-format command in NetBSD, and all I found was 'fdformat' which is for floppies. If anyone knows of a good SCSI format utility, please email us so we can mention it in a future column.

That disk was probably formatted by the Iomega ZIP Tools on win95. Note that partition 'd' is reasonable (size 196608, offset 0). You should be able to access the disk just fine with something like:

mount -t msdos /dev/sd0d /mnt	# replace 'sd0' with what dmesg said

That is what the pre-formatted disks I just bought look like. They seem to be partitioned slightly differently, so you have to use partition 'h'.

Tell mount to expect a DOS filesystem: 'mount -t msdos /dev/sd0h /mnt'.

No. Prepare to be initiated into the secret order of disklabellers.

1. Append the following six lines to your /etc/disktab file:

zip100|zip|IOMega Zip 100 MB Stuff Repository:\
	:dt=SCSI:ty=removable:rm#300:se#512:nt#32:ns#32:nc#192:\
	:pa#196608:oa#0:ba#4096:fa#512:ta=4.2BSD:\
	:pb#196608:ob#0:bb#4096:fb#512:\
	:pc#196608:oc#0:bc#4096:fc#512:\
	:pd#196608:od#0:bd#4096:fd#512:

2. Make sure the disk in the ZIP drive has no data you care about, and type:

disklabel -w -r sd0 zip100 stuff  # replace 'sd0' with your ZIP device

The 'zip100' refers to the text you just added to /etc/disktab. The 'stuff' is an optional, arbitrary string of some maximum length (ahem, is the actual maximum in the man pages?) which is referred to as the "disk pack label" and is just there to help you remember which disk is which. Later, when you run 'disklabel sd0' on this disk, early in the output you will see 'label: stuff'.

3. Construct a fresh BSD file system on the disk:

newfs /dev/rsd0a       # replace the 'sd0' part with your ZIP device

4. Add it to the system:

mount /dev/sd0a /mnt   # replace the 'sd0' part with your ZIP device
df /mnt

You should then see:

Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/sd0a       92383        0    87763     0%    /mnt

Enjoy!

That's the 'raw' version of the 'sd0a' device. If you look around in /dev you'll find that all disk device files have 'r' versions. The 'r' devices are used when you want the kernel to ignore the presence of the filesystem, among other things. Low-level programs like the disk-repair utility 'fsck' and some backup programs (and newfs) use the 'r' devices.

The default 'newfs' options are optimized for files that average 4K in size. If you will mostly use this disk for backups or large files, then you can reclaim a few megs easily, like so:

newfs -i 16384 /dev/rsd0a	# optimize for 16K files
newfs -i 65536 /dev/rsd0a	# optimize for 64K files

The default 'newfs' options are also optimized for a normal amount of disk traffic. The filesystem 'holds back' 5% of the space, which is kept spread throughout the disk. The kernel uses this extra space to stave off fragmentation in the filesystem. In the 'df' output, the percent 'Capacity' is computed without this 5%, so if 'df' reports 100% capacity you still really have 5% left. Only programs with root privilege are allowed to use up new space on a filesystem that is "100%" full. You can tell that this has happened when 'df' reports 101% or more full.

If you don't care about fragmentation performance, you can change the amount of space that is 'held back' by changing the 'minfree' parameter:

newfs -m 3 /dev/rsd0a	# only hold back 3%
newfs -m 0 /dev/rsd0a	# allow non-root users to fill the disk

These options cause 'newfs' to print the warning "changing optimization to space because minfree is less than 5%" which is the same as:

newfs -m 3 -o space /dev/rsd0a
newfs -m 0 -o space /dev/rsd0a

Of course, these options can be combined. To really squeeze your disk, use:

newfs -i 1024000 -m 0 -o space /dev/rsd0a

/dev/rsd0a: 196608 sectors in 192 cylinders of 32 tracks, 32 sectors
	96.0MB in 12 cyl groups (16 c/g, 8.00MB/g, 32 i/g)
super-block backups (for fsck -b #) at:
 32, 16448, 32864, 49280, 65696, 82112, 98528, 114944,
 131360, 147776, 164192, 180608,

mount /dev/sd0a /mnt
df /mnt

Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/sd0a       98095        0    98095     0%    /mnt

Beware, this filesystem will only allow 384 files or directories to be put on it. Each file consumes one inode, and the areas of the disk that may be used for inodes are reserved at 'newfs' time, to help avoid the need for frequent defragmentation of the filesystem. Each time you use 'ls', every inode referenced by that directory may be read in, so it helps to keep them packed into "islands" on the disk and not allow them to be scattered around.

The number of inodes can be computed by multiplying the "cyl groups" and "i/g" numbers in the 'newfs' output with each other.

I like to have two mount points, /z and /zro (which is read-only). This makes it easy to browse old backup disks without fear of accidentally touching them, and with minimal typing. To set this up:

mkdir /z /zro
echo "/dev/sd0a /z ffs rw,noauto 0 0" >> /etc/fstab    # careful! or
echo "/dev/sd0a /zro ffs ro,noauto 0 0" >> /etc/fstab  # edit fstab.

Indeed it is. The problem is that ZIP's are handled by the generic SCSI disk driver, so the device name of the ZIP drive is not easy to guess. The 'eject' program uses a static list of known device names (like "cd0a" and "fd0a"). You could hack 'eject' to know about your ZIP device, or symlink its device to /dev/zd0a and hard-code that name into 'eject'. The following verbose command works already, without changing 'eject' at all:

eject -d /dev/sd0d -t disk   # replace 'sd0' with your ZIP device

Not sure, but I would bet that it's a BIOS geometry problem. Try using this disktab entry instead (and give the different name to 'disklabel'):

zip100a|IOMega Zip 100 MB Stuff Repository, Adaptec controller geometry:\
	:dt=SCSI:ty=removable:rm#300:se#512:nt#64:ns#32:nc#96:\
	:pa#196608:oa#0:ba#4096:fa#512:ta=4.2BSD:\
	:pb#196608:ob#0:bb#4096:fb#512:\
	:pc#196608:oc#0:bc#4096:fc#512:\
	:pd#196608:od#0:bd#4096:fd#512:

... and if it doesn't work, as a last resort try:

zip100f|IOMega Zip 100 MB Stuff Repository, factory BIOS label geometry:\
	:dt=SCSI:ty=removable:rm#300:se#512:nt#64:ns#96:nc#32:\
	:pa#196608:oa#0:ba#4096:fa#512:ta=4.2BSD:\
	:pb#196608:ob#0:bb#4096:fb#512:\
	:pc#196608:oc#0:bc#4096:fc#512:\
	:pd#196608:od#0:bd#4096:fd#512:

With both of these, 'newfs' is likely to complain with some warnings. The resulting disk should still work, but it won't perform as well as it could.