From owner-freebsd-hackers Sat Sep 13 23:21:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24514 for hackers-outgoing; Sat, 13 Sep 1997 23:21:58 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA24506 for ; Sat, 13 Sep 1997 23:21:52 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA01041 for hackers@FreeBSD.ORG; Sun, 14 Sep 1997 08:21:51 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA09965; Sun, 14 Sep 1997 08:20:45 +0200 (MET DST) Message-ID: <19970914082044.BG34112@uriah.heep.sax.de> Date: Sun, 14 Sep 1997 08:20:44 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? References: <19970913165635.17336@lemis.com> <199709132207.PAA29890@usr03.primenet.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709132207.PAA29890@usr03.primenet.com>; from Terry Lambert on Sep 13, 1997 22:07:10 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > It is not an issue of retrying forever; typical BIOS implementations > will seek and retry. Typical FreeBSD implementations will seek and retry. UTSL. > I think the problem lies in the use of sector instead of track based > reads and writes, actually. Doing a sector at a time can add a lot > of slop-error. Why and how? If a FDC fails to detect the sector ID field reliably, i would call it `broken hardware'. The first sector ID field is not more magic than any other sector ID field, btw. Even full-track reads will have to decode each sector ID field separately (unless you're going to read a raw track, but that's nothing you would do except for debugging purposes). Terry, again, you don't know what you're talking about. Have you ever programmed a NE765/i8272 yourself? I doubt it. You would make more qualified comments if you had. > To keep multitrack writes streaming would require > two track buffers, BTW. Why? The inter-sector gaps of floppies are large enough to give the CPUs that are in use these days time to setup the next transfers. Let alone track-to-track seek times. (Our floppies don't use track skewing, so you always lose about 3/4th of a revolution when seeking. Plenty of time.) > The track buffer would act as a cache. Inter-track seeking would > be a bit slowed by this, but the MSDOSFS should probably see a good > performance improvement, especially since locality dictates that > most of the interesting pieces of the FAT will be in one buffer > or the other. If msdosfs is too stupid to cache the FAT, that's nothing a device driver should fix. There's the entire buffer cache in between. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)