Problems with the Vol Command and Floppy Disks

modified: 29 Mar 2005

This is an update of an article originally written for Minix 1.7 in 1996. Everything I wrote then still holds true if you are trying to write to raw floppy disks to make a Minix boot disk or to transfer large files to a Minix system. In fact, now (2005) the problem has become even worse, because floppy disks are less commonly used. This has two side effects: first everyone who has had a computer for a while has a stock of old floppy disks to recycle and thus is loathe to spend good money to buy high quality new disks. Second, because people use floppy drives less often, the drive itself is likely to have problems. On many systems the slot where you insert a floppy disk is also one of the main places where the cooling fan sucks in air from the outside, and a drive that has not been used for a long time can have a surprising amount of dirt inside, ready to be wiped off on, and thus to damage, the first disk inserted.

So, to the advice below I would add these points:

1. Before you blame Minix, check whether your floppy disk drive works with Windows or whatever other operating system is already installed on your computer, and ...
2. Consider purchasing a floppy disk drive cleaning kit. These kits are inexpensive and effective. See these notes on cleaning and testing floppy disks and drives.

Finally, if you have difficulties with floppy disks or if you have a system that has no floppy disk drive available consider using a different installation method. These days most systems have CD-ROM drives and are networked; these are two ways data can be introduced into a computer without using floppy disks. Minix 32-bit versions 2.0.3 and later come with the mtools utility which can transfer files from large Windows FAT partitions to a Minix partition, without the limitations of the old dosread program. And there are ways to start a Minix installation without booting from a floppy: at least one bootable Minix CD-ROM to RAM disk scheme is available, and the DOSMinix method allows you to run Minix using a Windows FAT file as a simulated disk. Both of these methods can be used as staging points for a standard Minix installation on a dedicated hard disk partition.

Here is the original version of this page:

On 17 Jan 1996 15:13:36 GMT James Skerritt (skerritt@magi.com) wrote
in comp.os.minix:

: I have minix installed OK, except that the USR.0? disks aren't all 
: installed, I've only got it to install up to USR.02 the other disks 
: haven't been used. any ideas?

You are probably having a problem with the vol command.  I think it
will be helpful if I answer the question: How does vol work?

A: Vol in write mode accepts a stream of data and writes it to a
device, pausing after every n blocks to prompt for insertion of a new
disk. In read mode vol generates a stream of data from a series of
disks. 

There is no file system on disks used by vol, and the disks are
not mounted; if a file system exists all the file system structures
will be overwritten with data. Thus vol can be used to transfer files
between operating systems, as long as both operating systems can read
raw disk sectors in the same format. But none of the normal file
system mechanisms to prevent use of bad sectors are available.

Vol cannot detect the end of a file or any errors within a file. In
write mode vol will terminate when the process preceding it in the
pipeline terminates. In read mode vol receives a SIGPIPE signal when 
the pipe it is writing to no longer has a process reading from it. 

In the ftp distribution of Minix 1.7 the USR.* and SRC.* disks contain
pieces of a big file -- you can think of it as USR.tar.Z or SRC.tar.Z,
although it never appears as a named file. In installing Minix this
stream of data is read, decompressed, and then extracted into
directories and files by the vol | zcat | tar pipeline. 

If vol stops asking for disks before you get to the last one it usually
means that the data is corrupt and zcat or tar reacted as if the end of
the file had been reached.  In this case tar is the only program in the
pipeline that can actually detect errors in the file, so the zcat | tar
pipe will break first when tar terminates, causing zcat to terminate
and the vol | zcat pipe to break.  The problem is most likely on the
last disk accepted, but it is possible it could have been the next-to
last one -- sometimes the pipeline will not detect the end of the data
before you are asked for one more disk.  It can also happen normally
that vol in read mode will ask for one more disk than was actually
written originally.  Just any old disk, including the one previously
read, will do in this case.

Since vol does a raw write of data to a disk with no file system there
are no file system mechanisms to lock out bad sectors.  (If you have
formatted disks under MS-DOS you have noticed sometimes you get a
message saying there are bad sectors, but the disk is still usable.
Minix has a mechanism, the badblocks command, to lock out bad sectors
on a Minix file system.) With vol you must use perfect disks.  If you
are not absolutely sure of your disks you should either check them (use
readall under Minix) or reformat them with a format program that
verifies all sectors are good (format -v under Minix), before you use
vol (or any other program that writes raw data to a disk) to write
disks to be read by vol. 

--
 Albert S. Woodhull
 Hampshire College, Amherst, MA     
 awoodhull@hampshire.edu