Date: Sun, 14 Sep 1997 14:26:54 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? Message-ID: <19970914142654.GG28248@uriah.heep.sax.de> In-Reply-To: <199709141017.DAA15075@usr06.primenet.com>; from Terry Lambert on Sep 14, 1997 10:17:45 %2B0000 References: <19970914082044.BG34112@uriah.heep.sax.de> <199709141017.DAA15075@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote: > Rewriting the track is intrinsically more reliable, because it > preserves the inter-sector gaps with less hysterisis. The tradeoff > is in read-before-write. There's no good option in the NE765 to write an entire track. You can do a multi-sector write, but the FDC still disassembles this into single write operations, with a read-before-write to find the respective sector ID fields. The only operation that writes an entire track without first reading the ID fields is FORMAT TRACK. > 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. But still, it's only a matter of whether the driver requests several WRITE SECTOR commands, or whether the FDC splits the multisector command into single WRITE SECTOR operations. As long as the inter- sector gap is large enough for the interrupt code to setup the next transfer (which is even on a 386/sx-16), you don't lose anything. (Sequential) floppy transfer only starts to suck if you start losing a single sector, since this means you lose an entire revolution. Our normal floppy speed (30 KB/s) tells me that we don't use revolutions (which would mean the speed drops below 25 KB/s), so the difference to the maximal theoretical speed is caused by the track-to-track seek, which indeed loses part of a revolution. I agree that this loss could indeed be handled by a track buffer, that does a read ahead of the sectors that are passing the head before the desired sector arrives, and could hand out the data out of this buffer if they are requested later on, which is likely. The problematic thing with this is that there's no means in the NE765 to say ``READ ANY SECTOR'', so you have to specify a ``READ ID'' first, losing this sector's worth of data, in order to know which sector to read next. > > 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. > Because of the need to synchronize, of course. Relative seeks are > not very reliable (see "The Undocumented PC" for details). Why are they not very reliable? All the seeks are relative. Van Gilluwe's chapter about floppies made me quickly aware that he's not very experienced in this field either, so take his statements with the necessary grain of salt. How else could he still write nonsense about ``head loading'', even though the last drives that did an on-demand head loading were the good ol' 8-inch drives? (Still true in the second edition, i verified this in a bookstore.) > 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. If the application wasn't quick enough to deliver more data, the track buffer wouldn't gain much either. You could only fall back to a sector-by-a-time mode then, or artificially defer the actual write operation (and bogusly report a ``good'' status to the caller), to collect more data in the meantime. Iff the application was quick enough to deliver more data, the track buffer doesn't gain you anything as well. The application could still issue a large write(2) syscall (e.g. 18 KB), which you split into single-sector transfers. Nothing's lost. You can do many not-so-simple, nitty-gritty things inside a floppy driver, but you should keep the old sentence in mind ``Never try to optimize something before you've profiled it.'' Track buffers belong into this class of non-optimizations. The only optimization i see is the above mentioned use of a track buffer to do read-ahead of unwanted but available sectors after a seek operation, in the hope that somebody is interested in the gathered data later on in the game. I have no doubts that it is possible to use a track buffer (Linux does, and IMHO NetBSD does, at least they do multi-sector transfers). Anyway, before i accept it as something useful, you have to prove first that it's really improving something more than your ego. ;-) > > 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. What the heck should the driver deal with FATs, i-node regions, or block pointers? It is a matter of filesystem implementations to take care of caching their data. It's a matter of drivers to make these data available, without any consideration about what data this might be. If a track buffer helps improving some filesystem performance, this only shows that the filesystem implementation has been poorly designed. > 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). What is wrong with caching these metadata in the buffer cache? UFS has way more (and way more scattered) metadata, and it has properly shown that storing these data in the buffer cache improves performance. > SVR3 actually had a working FT driver in the kernel, and it used a > double buffer so that it could rewrite during resynchronization This merely sounds like the above idea of making some use of the sectors that are currently passing by. In the case of optimizing this for writes, you have the additional problem that you need to reorder the device queue all the time. (There's no disksort() in FreeBSD.) This is needed in order to be able to correctly report the success status back to the caller for each sector. For raw device IO, this is impossible, since only one transfer is queued by physio(9) by a time. (Hmm, the driver could try to be smarter if this transfer is more than one sector's worth of data.) For filesystem operation, it can indeed be a win. -- 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?19970914142654.GG28248>