Date: Sun, 14 Sep 1997 10:17:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? Message-ID: <199709141017.DAA15075@usr06.primenet.com> In-Reply-To: <19970914082044.BG34112@uriah.heep.sax.de> from "J Wunsch" at Sep 14, 97 08:20:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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). Rewriting the track is intrinsically more reliable, because it preserves the inter-sector gaps with less hysterisis. The tradeoff is in read-before-write. The reason that this is more reliable is that rate at which write requests can be handled. Ideally, they will be chained in a single write command. Like I said, this screws with sector-at-atime I/O, because it needs read-before-write. Just like seeking into a block on a ufs and writing one byte needs read-before-write. > 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. I've hacked on the fd.c code locally to do track-based I/O in place of the sector-based I/O, mostly as proof of concept (I don't have a shitty fdc available for testing; sorry: I only buy good hardware). > > 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.) Because of the need to synchronize, of course. Relative seeks are not very reliable (see "The Undocumented PC" for details). You are assuming, incorrectly, that the process doing the writes will be ready-to-run by the time the next write is going to happen. This is a bogus assumption on a heavily loaded system. > > 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. I disagree; there should be a two track cache intrinsic to the floppy driver. The "other" track will always contain the fat during any sequential access, because the sequential access requires a traversal of the FAT chain. The MSDOSFS should cache the FAT before this is invoked, in any case, because of the concept of long fat chains, which may overrrun a track buffer (see the paper referenced in the previous posting). The idea is not to have the device driver fix it, but to have the data in device space ready for DMA by the time the next track is ready to go. When you get the interrupt, then you soo if the data is ready to go, and if not, do a resynchronize while you wait. This will take care of most of the issues. SVR3 actually had a working FT driver in the kernel, and it used a double buffer so that it could rewrite during resynchronization (the guy who wrote the SVR3 driver was actually in the office one floor below me at Univel in the Sandy, Ut, office of Novell... and he definitely knew his shit). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709141017.DAA15075>