Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!ssc-vax!bcsaic!paula
From: paula@bcsaic.UUCP (Paul Allen)
Newsgroups: comp.os.minix
Subject: Re: 3.5" disks, PS/2 model 50Z
Message-ID: <18528@bcsaic.UUCP>
Date: 3 Jan 90 00:40:02 GMT
References: <2879@dogie.macc.wisc.edu> <3060@plains.UUCP> <5032@ast.cs.vu.nl>
Reply-To: paula@bcsaic.UUCP (Paul Allen)
Organization: Boeing Computer Services AI Center, Seattle
Lines: 89

In article <5032@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <3060@plains.UUCP> overby@plains.nodak.edu (Glen Overby) writes:
>>I don't believe mknod allows
>>you to specify a size; just when the disk is make with mkfs.
>
>I know.  One can patch it with de, but admittedly a better scheme is needed.
>You can use mkfs, but then you get size 0, which works for most things,
>but not copying the device since it doesn't know when to stop.

I've worked up a scheme that might be better.  It's not complete, but
I've only invested about 6 hours so far.  I'll start with a bit of
motivation and then describe what I've done.

I got tired of the glacial speed of the floppy driver under 1.3 and
decided to add interleaving.  But since all my existing floppies were
written by the old driver, needed to be able to deal with both
interleaved and non-interleaved floppies.  Also, in order to do
interleaving, you need to know the sectors per track, which depends on
the drive/media combination.  But the driver tries different
combinations if if gets errors.  It seems like the driver ought to
return EOF (or something) if you try to access beyond the end of the
media, but you can't know what type of media you've got until you have
a successful transfer, which you can't have if the requested block is
off the end of the disk!  Aaaagh!

I've attacked my perceived problems in the 1.3 floppy driver with the
following scheme:

	- The minor device number encodes the drive number, whether to
	  use interleaving, and the drive/media combination.  Given the
	  drive/media code, one can look up stuff like the sectors per
	  track and blocks per disk.

	- The 'd' (drive/media combination code) variable in floppy.c
	  gets set by shifting and masking the minor device number.

	- The logic to try different values of 'd' is intact for the
	  odd situation (like booting :-) ) when the requested minor
	  device doesn't match the actual drive and media.  I'd like
	  to remove this and let an error just be an error.

	- A new subroutine fl_il() maps logical block numbers into
	  physical block numbers and knows how to do 2:1 interleaving
	  on 9- and 15-sector disks.  I don't have any 3" drives, and
	  haven't implemented 18-sector disk interleaving.

	- The driver now returns EOF when the requested logical block
	  is beyond the end of the media as specified by the minor
	  device number.

	- There are now quite a few floppy devices in /dev, and their
	  names reflect the specific configuration encoded in their
	  minor device numbers.  The device special files were created
	  with mknod, and do not contain sizes.

I'm thinking about fixing the kernel so that the default minor device
for floppy drive 0 specifies a 1.2M disk in a 1.2M drive without
interleaving (my standard setup).  It should probably be configurable 
via the makefile, or perhaps the default should be set based on what's 
in the drive at boot time.  Anybody have any thoughts?
 
The good news is that writing tarfiles to a 2:1 interleaved 1.2M floppy
is now twice as fast as with the old driver and reading tarfiles from
the same floppy is four times as fast as before.

The bad news is that having the driver return EOF at the end of the
volume doesn't have the same effect as putting the size in the inode.
For example, GNU tar complains about a short write and aborts at the end
of the first volume when writing a multi-volume archive.  With the old
driver and the old /dev/at0, gtar simply asked for the next volume to be
mounted.

I've been poking around trying to find the place in the code that uses
the inode size field to detect end-of-device, but haven't found it yet.
Has anybody run down this line of inquiry before?  Does what I've done
make any kind of sense?  Is this all moot because the 1.5 floppy is 10
times faster than 1.3?

(The reason I'm messing with 1.3 is that I need to back up my disk
before I let 1.5 touch it.  The thought of tar'ing my current 23M of
Minix data at 4-5 minutes per floppy is real discouraging!)

Paul Allen


-- 
------------------------------------------------------------------------
Paul L. Allen                       | pallen@atc.boeing.com
Boeing Advanced Technology Center   | ...!uw-beaver!bcsaic!pallen