Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!think!linus!gwr From: gwr@linus.UUCP (Gordon W. Ross) Newsgroups: comp.os.minix Subject: Re: 3.5" disks, PS/2 model 50Z Message-ID: <85654@linus.UUCP> Date: 5 Jan 90 21:34:42 GMT Reply-To: gwr@linus.mitre.org Organization: The MITRE Corp., Bedford, MA Lines: 102 In article <18528@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: [ Much deleted for brevity ] > I got tired of the glacial speed of the floppy driver under 1.3 and > decided to add interleaving. [ discusses problems identifying media types ] > 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 good way to handle this is to add another minor device type which is a "media sensitive" device useful for reading and writing formatted diskettes. The other minor devices corresponding to particular diskette formats would be useful with a diskette formatting program. > - 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. Sector interleaving, as I understand it, should not necessitate any change in the mapping of logical-to-physical disk blocks. When the floppy disk controller (FDC) is asked to read or write a sector with a particular ID the FDC waits for the sector with that ID to rotate under the read/write head and then carries out its work. The physical positioning of these sectors and the order of sector ID marks on the track depends only on the interleave table used when the the disk was formatted. With this understood, I think it would be a big mistake to re-map the order of logical blocks to something other than sequential sector ID numbers. Sector interleave should be the concern of the formatter. > - The driver now returns EOF when the requested logical block > is beyond the end of the media as specified by the minor > device number. [ see below ] > > - 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? Yes. Boot (and otherwise read) from the "media sensitive" device. > 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. Actually, the return value to use is not so simple. After studying our Sun, Sys V/386, and GNU tar (by John Gillmore) it seems that the following behavior is expected of an mtio(4) compatible device: + Sequential reads past the end of the device should return zero. (maybe EOF on subsequent reads?) + Seek past the end should return error, EIO (I/O error). + Sequential writes past the end of the device should return error, ENOSPC (No space). > > 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. Isn't the device size check done in kernel/floppy.c: do_rdwt() ? > Paul L. Allen | pallen@atc.boeing.com > Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen -- Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org The MITRE Corporation UUCP: {decvax,philabs}!linus!gwr Burlington Road, Bedford, MA 01730 (617) 271-3205 -- Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org The MITRE Corporation UUCP: {decvax,philabs}!linus!gwr Burlington Road, Bedford, MA 01730 (617) 271-3205