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? Message-ID: <19970914082044.BG34112@uriah.heep.sax.de> In-Reply-To: <199709132207.PAA29890@usr03.primenet.com>; from Terry Lambert on Sep 13, 1997 22:07:10 %2B0000 References: <19970913165635.17336@lemis.com> <199709132207.PAA29890@usr03.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970914082044.BG34112>