cwr@pnet01.cts.com (Will Rose) (08/08/90)
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.
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. I tried a couple of different block sizes, 512B (the
default) and 1KB, and read the floppy device into a file on a hard disk;
curiously, one blocksize was slower reading onto the hard disk and the
other was slower reading onto the floppy. The times were:
dd if=/dev/fd1 of=file bs=1k count=1440 takes 15 min.
dd if=file of=/dev/fd1 bs=1k count=1440 takes 7 min.
dd if=/dev/fd1 of=file count=2880 takes 6 min.
dd if=file of=/dev/fd1 count=2880 takes 12 min.
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
performance still seems awfully slow. The machine is a 10MHz XT running
(very) standard 1.5.10.
All suggestions gratefully received - Will
-----------------------------------------------------------------------
"If heaven too had passions | Will Rose
even heaven would | UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cw
grow old." - Li Ho. | ARPA: crash!pnet01!cwr@nosc.mil
| INET: cwr@pnet01.cts.com
UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cwr
ARPA: crash!pnet01!cwr@nosc.mil
INET: cwr@pnet01.cts.comcechew@bruce.cs.monash.OZ.AU (Earl Chew) (08/09/90)
In <3851@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes: >took a long time. I tried a couple of different block sizes, 512B (the >default) and 1KB, and read the floppy device into a file on a hard disk; >curiously, one blocksize was slower reading onto the hard disk and the Perhaps Bruce can provide some concrete information on this, but I generally set the block size to the size of one track to give the driver some hope of not missing sectors. (I'm not sure if the driver does track readahead) You may care to experiment with track sized block sizes. Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 ARPA: cechew%bruce.cs.monash.oz.au@uunet.uu.net ACS : cechew@bruce.oz ----------------------------------------------------------------------
wayne@csri.toronto.edu (Wayne Hayes) (08/09/90)
In article <3851@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes: >curiously, one blocksize was slower reading onto the hard disk and the >other was slower reading onto the floppy. The times were: > > dd if=/dev/fd1 of=file bs=1k count=1440 takes 15 min. > dd if=file of=/dev/fd1 bs=1k count=1440 takes 7 min. > dd if=/dev/fd1 of=file count=2880 takes 6 min. > dd if=file of=/dev/fd1 count=2880 takes 12 min. > >Are these times typical, and is there any input buffering or whatever that >could speed things up? After some experimentation, I found that the larger the buffer size, the faster it worked. I started out with bs=10240 (10K), count=144, but hey, since *all* the floppy sizes are divisible by 30K, I now use dd if=df1 of=file bs=30720 count={***} where {***} = (disk size) / (30720). This works pretty fast. -- "The number of programs that can be done with the Hubble Space Telescope has always greatly exceeded the time available for their execution, and this remains true even with the telescope in its current state." -- HST Science Working Group and User's Commitee Report, 1990 June 29. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
ghelmer@dsuvax.uucp (Guy Helmer) (08/09/90)
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
brucee@runxtsa.runx.oz.au (Bruce Evans) (08/11/90)
In article <3851@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes: >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 It only works for DOS disks. It reads the a parameter block on the first sector, and gets confused if there is Minix `garbage' there. Even 360K disks may be treated as single-sided. > dd if=file of=/dev/fd1 bs=1k count=1440 takes 7 min. > dd if=/dev/fd1 of=file count=2880 takes 6 min. This is normal on a 5MHz XT (except bs=1k ought to be the fastest). The floppy driver is too slow. It spends several msec processing in between blocks when it can only aford 1msec. This results in 1 block of i/o per revolution. It takes about a 10MHz AT to keep up (at least for a 1200K disk), giving an i/o time of about 40 sec for copying an 80-track floppy to a file on a hard disk. For a 1440K disk you need a couple more MHz. >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 There's already considerable buffering in FS. Otherwise the time for 512b blocks would be twice as long as for 1k and the time for 1k might be 9 times as long as for 9k. (The best block size is the smallest multiple of the head sizethat gives a whole number of blocks, i.e. 1 * 9k here, 2 * 4.5k, 2 * 7.5k, etc.) Your times are about 9 times as slow as they would be if the floppy driver was taking advantage of the buffering. I wondered if anyone used the `safe' filesytem update. It's not so safe for the drive (more wear) or the computer (user may get tired of waiting and get something faster :-). Actually, it hardly matters here because no inodes are being written to the floppy. -- Bruce Evans Internet: brucee@runxtsa.runx.oz.au UUCP: uunet!runxtsa.runx.oz.au!brucee (My other address (evans@ditsyda.oz.au) no longer works)