usenet@cps3xx.UUCP (Usenet file owner) (04/06/90)
In article <10624@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >Only some devices actually need to implement bad block mapping; >SCSI and other already do it below the protocol level. That alone >should be a clue to the fact that I'm not the only one who thinks >that bad block mapping is a low-level problem. But SCSI devices have their own controller, which performs all of the error checking, etc. on the prepping and then just ignores bad areas of the HD (i.e. they are not counted). On the Amiga floppy system, wouldn't the Amiga device driver be responsible for performing this (or similar) function SINCE THERE IS NO SCSI CONTROLLER FOR THE DRIVE??? >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > Too much of everything is just enough ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-Agreed. :) __ /..\ ('`) Chris Dailey /_/\_\ dailey@cpsin1.cps.msu.edu |______| (_ ][ _) ``''
mwandel@tiger.waterloo.edu (Markus Wandel) (04/07/90)
In article <5530@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > ... As you pointed out, taking a multi-11K hit for spare tracks is a bit > much.... Why does everybody keep talking about multi-11K hits? You only have to take out a track (5.5K) for a bad block, not the whole cylinder. And I would say that losing disk space in increments of 0.7% (that's how much of the total capacity one track is) is not bad. Of course, the bad block mapping would have to be built into the file system, since the device driver could not "pretend" it always has a flawless 880K disk, because there are no spare tracks. I just can't understand what is so evil about doing bad block mapping at the file system level. Yes, MS-DOS does it, and does it well. All we need on the Amiga is a special "file", linked in to the root block for example, which stores the addresses of all the bad blocks. Disk optimizers could skip these, and the validator could allocate them in the bitmap right off. No problem. Better yet, the format program could automatically link in any blocks that it is unable to verify correctly in the format phase. No problem. And since the format program is the only thing that creates the list, it is the only place where special code would have to account for the trackdisk.device's unusual behaviour. Assuming an unused longword could be found in the rootblock, this scheme could even be implemented transparently to old file systems. They would just validate the disks incorrectly, with no worse results than we now have. Now for the benefits: 1. Damaged floppies can be used with only a small reduction in capacity (yes, 5.5K at a time but so what). 2. PD programs would appear very quickly which can map out bad blocks on the fly, without reformatting a disk. 3. Device driver writers for things other than SCSI would not have to to worry about some nightmare algorithm which allows multiblock read/write commands while still skipping bad blocks (and it is a nightmare algorithm, I've thought about doing it for my 80MB SCSI disk on which bad block mapping is broken). 4. Users wouldn't be stuck with whatever half-baked schemes SCSI interface implementers have come up with to allow access to the underlying bad block management. In particular, a lot seem to allow bad block mapping only at low-level format time, something which SCSI drives do not demand and the above-described scheme does not either. 5. The scheme described could be used to arbitrarily reserve areas of the disk to be immune from use by the file system or a disk optimizer, and immune to being deallocated by the disk validator. Finally, we would have a legal way to store copy protection tracks, absolute code, long boot-sector code, and other oddities on a floppy disk legally. 6. Use of the scheme described would be entirely optional; no penalty whatsoever would be incurred if the disk is in fact flawless, and bad-block mapping at the device driver level could still be done if desired. Markus Wandel mwandel@tiger.waterloo.edu (519) 884-9547
Jim.Locker@afitamy.fidonet.org (Jim Locker) (04/09/90)
In my system, my SeaGate ST296N tracks its own bad blocks and the Amiga
doesn't have to worry about it.
Jim Locker
--
----------------------------------------------------------------------------
AFIT Amiga Users BBS/UFGateway |Jim Locker - via FidoNet node 1:110/300
1:110/300 Dayton, Ohio |UUCP: afitamy!Jim.Locker
(513)-252-7681 |ARPA: Jim.Locker@afitamy.fidonet.org
----------------------------------------------------------------------------daveh@cbmvax.commodore.com (Dave Haynie) (04/10/90)
In article <5530@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <10624@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >> As I pointed out, that's not ture. And the bad end of it is that the >> filesystem would have to have device-level knowledge of each and >> every device to effect the bad-block mapping. >No it wouldn't. All it needs to do is mark a bad block as "bad", take a >new block off the free list, and use it instead. The *only* device this >wouldn't work for is trackdisk.device... which would need some special >voodoo. Can you be absolutely sure that trackdisk.device is the only device that'll ever be a bit weird? Just because it's the only non-block-oriented device right now doesn't imply that it always will be. And how about devices that automatically handle bad block mapping below the FileSystem level? In that case, you could very easily end up mapping any bad block twice. >Either that, or add the bloody track mapping to td.dev, let format pre-map >bad tracks out, and give us a version of disksalv or diskdoctor that's >worth a damn. The current situation is intolerable. Personally, I think the current DiskSalv is worth a damn. Maybe two. It can't re-create data that just plain doesn't exist anymore on the floppy, but if you ever find a file it can't recover, *PLEASE* send me a copy of that disk. I want disks that DiskSalv can't recover. I mean, I can make my own bad disks under 1.3 by repeatedly yanking and inserting, but some errors you just can't re-create. >I've given up trying to do development off floppies altogether... they're >just not reliable enough (and, yes, my drives have been cleaned, checked, >aligned, landered, starched, and pressed). Well, I used 'em for a few years and never had any serious problems. Sure, there were occasional problems, and I would be the last one to argue against some form of block or track mapping on the floppies. Even though I did work off floppies for a long time, I wouldn't recommend them for professional code development on any machine. >But that's beside the point. It's really nice to have hardware that hides >bad sectors. But that doesn't mean that drivers should do so as well. If >you're going to have the 68000 mapping sectors around, why not do it at a >level that knows what those sectors mean? I think it's as important to do it at a level that knows where those sectors actually are. The FileSystem only gets a logical picture of what's on a device. It can't possibly know where the blocks actually exit. They could, for instance, be spread out over several disks. > _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
peter@sugar.hackercorp.com (Peter da Silva) (04/14/90)
In article <10735@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: > Can you be absolutely sure that trackdisk.device is the only device that'll > ever be a bit weird? Just because it's the only non-block-oriented device > right now doesn't imply that it always will be. No, it's NOT the only non-block-oriented device. How about RAM:? Or networks? But more to the point, it's the most common device out there: everyone's got it and uses it at least for software installation. Most people use it for everything. It should be properly supported... and that means bad block handling *somewhere*. And, of course, turnabout is fair play. Just because it's the only device that presents an imperfect volume to the FS, does that imply it always will be? > And how about devices that automatically handle bad block mapping below the > FileSystem level? In that case, you could very easily end up mapping any > bad block twice. I don't see how, if the driver or hardware "presents a flawless device" to the filesystem, the filesystem should never map a block. > Personally, I think the current DiskSalv is worth a damn. Maybe two. It > can't re-create data that just plain doesn't exist anymore on the floppy, but > if you ever find a file it can't recover, *PLEASE* send me a copy of that > disk. I want disks that DiskSalv can't recover. I mean, I can make my own > bad disks under 1.3 by repeatedly yanking and inserting, but some errors you > just can't re-create. I can't use DiskSalv to recover *anything*. Well, that's not true... once I get it to work it works well enough. I'm pretty sure I'm up to date on it, but it frequently insists that the output device is full... even when it's a freshly formatted floppy! And what about hard disks... how do recover them??? Well, I can assume that we'll never see a FS that handles bad blocks. How about a trackdisk.device that does? You have to put it *somewhere*. And enough of this "buy a hard disk" or "buy an Amiga 2000". If I had that kind of disposable income I would have. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'