Date: Wed, 22 Jan 1997 21:22:47 +1100 From: Bruce Evans <bde@zeta.org.au> To: freebsd-hackers@freebsd.org, jgrosch@sirius.com Subject: Re: ffs on ZIP drive (fwd) Message-ID: <199701221022.VAA13789@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701221022.VAA13789>