Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!natinst!uudell!loft386!dsuvax!ghelmer
From: ghelmer@dsuvax.uucp (Guy Helmer)
Newsgroups: comp.os.minix
Subject: Re: PC Minix and 1.44MB floppies
Message-ID: <1990Aug9.143410.9703@dsuvax.uucp>
Date: 9 Aug 90 14:34:10 GMT
References: <3851@crash.cts.com>
Organization: Dakota State University
Lines: 60

In <3851@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes:

>I recently had to copy some Minix filesystems on 1.44MB disks on an XT with
>one 360KB and one 1.44MB floppy.  MSDOS 3.3 diskcopy works for 360KB disks,
>but I found that 'diskcopy b: b:' attempted to reformat the target disk to
>15 sectors/track, ie. the spt for a 1.2 MB device.  This despite the fact
>that the disk was already formatted to 18 spt.  I can't believe diskcopy
>had kept bugs so long, but so it seems.  This may be the problem reported
>by those trying to move Minix to 3.5 disks of any size - I don't have a
>720 KB disk to test with diskcopy.

Well, it's not a bug in DOS 3.3.  When the AT came out with 1.2Mb
floppies and DOS 3.0, Microsoft put a floppy id byte in the boot record that
tells DOS what format the disk is.  Every time a disk is used under DOS,
DOS checks that byte so it knows how many sectors per track and
tracks per side are on the disk.  MINIX keeps the superblock
where DOS keeps the boot record, so when _any_ DOS 3.0 or higher
utilities are used to work with a MINIX disk, nothing is guaranteed
to work or fail :-).  Moral: use BIOS-level utilities or
lower with MINIX disks under DOS.  (BTW, I have written Microsoft C
programs to read and write disks using the BIOS under DOS, if
anyone's interested)

>My next shot was to use dd under Minix (I wanted to keep file time and date
>stamps intact, and move seemed a bit risky).  This worked, but the copying
>took a long time.

What happens if you use a block size that matches the data in a track,
like 4608 or 9216 for a 360K disk, or 7680 or 15360 for a 1.2M disk?

Seems like you have some real time-wasting going on because the
small block sizes generate lots of floppy requests; after servicing
a request, there is (relatively) quite a bit of time spent by the o/s
and 'dd' while the block that was read is written to the output file.
Meanwhile, the floppy is spinning away, and by the time the next
read request comes, it probably takes on average half a rotation of
the floppy before the correct sector is found.

Big block sizes should cut the time drastically.

>Are these times typical, and is there any input buffering or whatever that
>could speed things up?  I'm using a 'safe' filesystem, with blocks written
>out to the disk immediately rather than buffered on the output; but the

Ooooo...  Very big performance killer, forcing immediate writes...

>performance still seems awfully slow.  The machine is a 10MHz XT running
>(very) standard 1.5.10.
> 
>All suggestions gratefully received - Will

I hope this helps.

>"If heaven too had passions  | Will Rose

-- 
Guy Helmer
work: DSU Computing Services, Business & Education Institute    (605) 256-5315
play: MidIX System Support Services                             (605) 256-2788
dsuvax!ghelmer@cs.utexas.edu, ...!bigtex!loft386!dsuvax!ghelmer