Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: A plea for bad block handling in the file system. Message-ID: <54019@sun.uucp> Date: 20 May 88 20:09:41 GMT References: <2009@sugar.UUCP> <7144@swan.ulowell.edu> <2026@sugar.UUCP> Sender: news@sun.uucp Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 80 [Normally I wouldn't do this but I am between compiles ...] In article <2026@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <7144@swan.ulowell.edu>, page@ulowell.UUCP writes: >> And I'll point out again that it's none of the FS' business what the >> physical device looks like. Let the driver present a perfect pack to >> the file system. > >Since the drivers (demonstrably) don't do this, this is really not >a very good argument. Peter, neither the drivers nor the filesystem do this so the question is : "We are going to bad block handling, should we put it in the filesystem or the driver?" Since putting it in the driver is *much* easier than putting it into the filesystem, that is where it belongs. The reasons : The Driver has a very unclutterd view of the world and can spare out bad blocks cheaply on the fly. The filesystem writes block 23222 and the driver writes it to the disk, it gets a hard write error so it spares out the block and then does the write again. The device may be capable of sparing bad blocks itself, in which case the code can be eliminated completely. If the filesystem is checking all the time for bad block sparing opportunities it will be arbitrarily degraded in performance for all devices. >> Sure, duplicated code in dozens of filesystems. > >There are today, and will be as far as I can forsee, a lot more drivers than >filesystems. Also, you (or Commodore, rather) have control over the filesystem. >The drivers are written by dozens of people. You haven't considered that a) the 1.3 Mount command allows you to specify arbitrary filesystems for mounted devices and b) Matt dillion has published an example of a filesystem that anyone can understand. What this means is that people who may have a couple of floppies and a hard disk (two drivers), may have several file systems. There is the Current Filesystem, the Fast Filesystem, there could be (and probably will be) an MS-DOS filesystem, maybe an implementation of the Berkeley 4.2 Filesystem, then of course people like Matt will write there own that do blazingly fast icon lookups or optimize scatter loading so there will a 'Matt Filesystem' possibly a very slow but very space efficient Archive Filesystem, if you have a SCSI tape you might want a Tape Filesystem. Get the picture? >> Not today, but eventually. >I can't see what you could possibly mean by this. See above. >> Protocols in dealing with bad blocks between file systems >> and drivers will expand.. >There's already a protocol by which a driver can tell a filesystem >it's got a bad block. It's called an error. No that is not a protocol that's a status. How does the filesystem know it is a bad block? Maybe someone just switched off power to the drive, maybe they ejected the disk, maybe there is a loose connection in the cable. "The driver will send a 'bad block' error status" you might say, and I would say "If it already knows that the block is bad why doesn't it go ahead and spare it out?" >> So should the driver. And the beauty is it doesn't care what the data is. > >So now you have another layer of complexity between the file and the >hardware. Something else to go wrong. The filesystem already has pointers >to the block. Why not use them? >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter Not true, the driver doesn't care what a block means, if it can't write to it then it can substitute a new block with impunity as long as it keeps a mapping of this old block to the new block, read failures must be treated somewhat more catastrophically(sp?) because it means that actual data may be lost, however in practice this is a very rare occurance because generally if the write succeeds (even if the block is 'bad') the the subsequent read will succeed as well. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.