From owner-freebsd-hackers Wed Jan 22 02:25:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA27043 for hackers-outgoing; Wed, 22 Jan 1997 02:25:29 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA27035 for ; Wed, 22 Jan 1997 02:25:26 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id VAA13789; Wed, 22 Jan 1997 21:22:47 +1100 Date: Wed, 22 Jan 1997 21:22:47 +1100 From: Bruce Evans Message-Id: <199701221022.VAA13789@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, jgrosch@sirius.com Subject: Re: ffs on ZIP drive (fwd) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I recently added a SCSI ZIP drive to my FreeBSD system. I've taken a stab >at at putting a file system on one of the disks. The following steps will >place a file system on the disk. > > * scsiformat sd2 > - Takes about 7 to 9 minutes to format Aren't ZIP disks preformatted? Mine were. They were even soft partitioned and soft formatted with one partition at offset 32 in slice s4 and an almost empty MSDOS file system in the slice. The easiest way to put a ufs on such disks is to run /sbin/fdisk to change the slice type from MSDOS to FreeBSD. Then disklabel them and newfs them as usual. If you don't want to use partitions, clear the partition table using `dd if=/dev/zero of=/dev/rsd2 count=1'. This takes about 40 msec :-). > * disklabel -w -r sd2 zipdisk > - The following entry is in my /etc/disktab. I've forgotten who > posted this to the mail list. > > zipdisk|100 MB ZIP disk:\ > :ty=removeable:dt=SCSI:\ > :se#512:nt#64:ns#32:nc#96:\ > :pa#196576:oa#0:ta=4.2BSD:\ > :pc#196576:oc#0: This disktab entry has several minor bugs: - ZIP disks are only 96 MB. - the size of the `c' partition is 32 less than the size of the whole disk (32*64*96 = 196608). The preformatted MSDOS partition has offset 32, but this is irrelevant for unpartitioned disks. Using a too-small value for `pc' justs wastes space and causes warnings if the system was booted with -v. The entry is more seriously wrong for the partitioned case. It describes a disk with 32*64*96 = 196608 sectors, but the slice has only 196576 sectors. Use nc#95 and su#196576 to describe the slice properly. /etc/disktab is inconvenient to use. The simplest way to label the whole of a ZIP disk is: dd if=/dev/zero of=/dev/rsd2 count=2 # count=1 would have worked for an unlabeled disk. count=2 # is to clear both the partition table in sector 1, if any # and the label in sector 2, if any. disklabel -Brw sd2 auto disklabel -e sd2 # edit to add partitions other than `c' The `auto' type only works for dedicated disks. `disklabel -Brw sd2 auto' is equivalent to: disklabel /dev/rsd2 | disklabel -BRr sd2 /dev/stdin Here the first disklabel prints the automatically generated label for the whole disk (/dev/rsd2) to stdout and the second disklabel interprets its input file /dev/stdin and turns it into a label for the BSD compatibility slice on the disk (sd2). The compatibility slice happens to cover the same sectors as the whole disk in this case. More complicated cases can be handled by editing the label running the second disklabel, either in a pipeline or directly: disklabel /dev/rsd2 >/tmp/foo $EDITOR /tmp/foo # reduce all relevant sizes for slice s2 disklabel -BRr sd2s2 /tmp/foo # apply label to slice s2 >This is all well and good. It works nicely but I have two problems: the >first is when I mount the disk I get the following on my xconsole > > sd2(ahc0:5:0): UNIT ATTENTION asc:28,0 > sd2(ahc0:5:0): Not ready to ready transition, medium may have changed > sd2(ahc0:5:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > sd2 could not mode sense (4). Using ficticious geometry This bug is very old. It is normal after a disk change, and seems to be harmless. Debugger("") is sometimes caled too. > sd2: invalid primary partition table: no magic This is caused by not writing boot blocks to the disk. Use `disklabel -B...' to write boot blocks. > sd2: raw partition size != slice size > sd2: start 0, end 196607, size 196608 > sd2c: start 0, end 196575, size 196576 This is caused by the `c' partition size being 32 smaller than necessary. See above. >the other problem is > >superior# df . >Filesystem 1024-blocks Used Avail Capacity Mounted on >/dev/sd2c 95343 1 87715 0% /mnt >superior# > >It's bad enough that you don't get 100 meg that you would think but where >did the other 7.6 meg go to ? I understand that some gets lost in laying There were 96*1024 = 98304 blocks to begin with. 16 were lost by using the wrong size for the partitions :-). 98304-16-95343 = 2945 were used or reserved for metadata. 95343-87715 = 7628 = 8% of 96343 were reserved for efficient block allocation (see other replies). About 11% is reserved altogether. Wastage can be reduced using newfs options and/or tunefs. Bruce