peter@sugar.UUCP (Peter da Silva) (05/17/88)
There's nothing that can be done about the reliability problems caused by the lack of firewalls between sectors, but I'd just like to make another plea for bad block handling in the filesystem. That's where it belongs: not duplicated dozens of times in dozens of drivers. Not only does this cut down on duplicated code, but it's also better because the filesystem has more information about what that bad block *means*. For example: a write error on a data block in a file or a file header block should not be fatal: the FS should be able to move the block elsewhere. In fact about the only write error that can't be recovered would be one in the root directory, and even then workarounds can be made. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
page@swan.ulowell.edu (Bob Page) (05/18/88)
peter@sugar.UUCP (Peter da Silva) wrote: >I'd just like to make another plea for bad block handling in the filesystem. 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. >That's where it belongs: not duplicated dozens of times in dozens of drivers. Sure, duplicated code in dozens of filesystems. Not today, but eventually. Protocols in dealing with bad blocks between file systems and drivers will expand, and soon everyone on USENET will be discussing how to 'standardize' the protocols for filesystems talking to drivers, and how bad blocks should be handled. >but it's also better because the filesystem has more information >about what that bad block *means*... FS should be able to move the >block elsewhere. So should the driver. And the beauty is it doesn't care what the data is. >In fact about the only write error that can't be recovered would be >one in the root directory, and even then workarounds can be made. Why work around it? The driver doesn't care what the data is - if the block is bad, revector it to another block. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
brianm@sco.COM (Brian Moffet) (05/19/88)
In article <2009@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >There's nothing that can be done about the reliability problems caused by >the lack of firewalls between sectors, but I'd just like to make another >plea for bad block handling in the filesystem. > I would like to second this motion. Especially on a hard disk, I am dreading the time I have to reformat a partition due to a bad block. I should be able to run a program (badtrk ?) and say cylinder/head blah is bad or sector blah is bad. I realize I would have to take the chance of loosing this data, but _everyone_ does backups, right? :-) -- Brian Moffet brianm@sco.com {uunet,decvax!microsof}!sco!brianm The opinions expressed are not quite clear and have no relation to my employer. 'Evil Geniuses for a Better Tommorrow!'
peter@sugar.UUCP (Peter da Silva) (05/20/88)
In article <7144@swan.ulowell.edu>, page@ulowell.UUCP writes: > peter@sugar.UUCP (Peter da Silva) wrote: > >I'd just like to make another plea for bad block handling in the filesystem. > 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. > >That's where it belongs: not duplicated dozens of times in dozens of drivers. > 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. > Not today, but eventually. I can't see what you could possibly mean by this. > Protocols in dealing with bad blocks between file systems > and drivers will expand, and soon everyone on USENET will be > discussing how to 'standardize' the protocols for filesystems talking > to drivers, and how bad blocks should be handled. There's already a protocol by which a driver can tell a filesystem it's got a bad block. It's called an error. > >but it's also better because the filesystem has more information > >about what that bad block *means*... FS should be able to move the > >block elsewhere. > 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 -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
jesup@cbmvax.UUCP (Randell Jesup) (05/20/88)
In article <573@viscous> brianm@sco.COM (Brian Moffet) writes: >In article <2009@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >>There's nothing that can be done about the reliability problems caused by >>the lack of firewalls between sectors, but I'd just like to make another >>plea for bad block handling in the filesystem. > I should be able to run a program (badtrk ?) and say >cylinder/head blah is bad or sector blah is bad. >Brian Moffet brianm@sco.com {uunet,decvax!microsof}!sco!brianm You've said it. It is quite possible to write a program to assign bad blocks to files in a 'dhX:BAD' directory. It requires knowing the format of the filing system blocks, but really would be rather simple. You, or Peter (who seems to want this bad), or anyone else who is interested could probably get this up and running in a couple of days, given examples from Fish Disks, and info on the FFS block layout (very similar to SFS except data blocks are 512 bytes of data.) Go to it. Randell Jesup {uunet|ihnp4|allegra}!cbmvax!jesup
jojo@astroatc.UUCP (Jon Wesener) (05/21/88)
Since the current trend is to put the bad block handling
in the drivers, (probably so the file system doesn't have to know
about bad blocks or how to handle them (such as track slipping,
sector forwarding, or bad block maps like MS-DOG land)) and because
we don't have an euivalent to bad144... How about a work around.
How hard would it be to write a program to allocate specific
blocks on the the hard disk to a file? You could then create a
special file, hidden somewhere appropriately which you could allocate
bad sectors to, and forget about them. This all depends on how easy
it is to allocate specific disk blocks.
I sure know I don't want to have to reformat my hard disk just
to lock out a bad sector.
--j
--
jon wesener
... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!jojo
"do us all a favor, get yourself a spine." -- replacementscmcmanis%pepper@Sun.COM (Chuck McManis) (05/21/88)
[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.
louie@trantor.umd.edu (Louis A. Mamakos) (05/21/88)
In article <2026@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <7144@swan.ulowell.edu>, page@ulowell.UUCP writes: >> peter@sugar.UUCP (Peter da Silva) wrote: >> >I'd just like to make another plea for bad block handling in the filesystem. > >> 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. You're wrong. The device driver (or on-board microcode) for the A2090 controller does this. Why add needless complexity to the file handler when the device driver know how to do this better? And if you're fortunate, the disk controller or the drive (e.g. SCSI drives) will do the bad block management for you. I can't understand why everyone seems to have problems with floppy disks. Between my A1000 that I had for 2.5 years (since day 0), and the A2000 I've had since then, I've only had 2 or 3 disks ever crap out on me out of literally hundreds. Maybe I just live right or something. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
mrr@amanpt1.zone1.com (Mark Rinfret) (05/22/88)
In article <1025@astroatc.UUCP>, jojo@astroatc.UUCP (Jon Wesener) writes: > > Since the current trend is to put the bad block handling > in the drivers, ... goes on to talk about bad block handling... > ... > This all depends on how easy > it is to allocate specific disk blocks. Since you brought it up, I'd like to grab the opening. How about some lower-level disk support along the lines of: /* The following flags determine the "flexibility" level of the request. * Of course, the letters BARF are an abbreviation for "Block Allocation * Request Flag", not an allusion to some of the feedback I'm expecting. :-) */ #define BARF_RIGID 0x00 /* No substitutions. */ #define BARF_PARTIAL_ALLOCATION 0x02 /* Allow less than requested. */ #define BARF_SUBSTITUTE_BLOCK 0x04 /* Allow alternate starting block. */ typedef struct { /* This field specifies where we'd like to start the allocation. If * it's zero, we don't give a hoot. */ LONG bar_StartingBlock; LONG bar_desiredCount; /* How many blocks we'd like to get. */ LONG bar_ActualBlock; /* The system sets bar_ActualBlock to the first block allocated. */ LONG bar_ActualCount; /* How many blocks we actually got. */ WORD bar_Flags; /* Request flexibility flags. */ WORD bar_Result; /* Completion code. This can be a combination of the flags above or other status codes indicating the type of failure (bad flags, no blocks, etc. */ } BlockAllocationRequest; WORD AllocateBlocks(request); BlockAllocationRequest *request; where return result == status (copy of bar_Result) request is a pointer to a BlockAllocationRequest, filled in by the user prior to the call, and containing useful info after the call. Of course, the above is all probably implemented in 1.3 or the new FFS or something else I don't know about. Also, please don't take my model above too literally. I'm sure it could all be done with some permutation of the standard I/O request. Support as I've outlined above would allow the creation of smart file copy programs, possibly even background hard disk optimizers (Holy defragmentation, BatMan!). Since I'm started, how about another one: BOOLEAN SetFileInfo(lock, info); struct FileLock *lock; struct FileInfoBlock *info; This routine would do a smart copy of certain file parameters defined by <info> to the file defined by <lock>. For starters, the info to be copied would include: File Name (useful if copying a file to a file of the same name on a different device or directory) File Comment (I like these - let's use 'em!) File creation/modification date File permission flags While the individual pieces of support are already in AmigaDos, it sure would be nice to see them bundled up into one coherent call. Heck, programmers might even be encouraged to do things right if it's easy enough! Programs like vi might remember that my filename was capitalized. The multitude of copy programs might even maintain vital statistics (no holy war discussions on copied file dates, please). Thanks for your time... > > --j > -- > jon wesener Nice idea, jon. Mark > ... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!jojo > > "do us all a favor, get yourself a spine." -- replacements -- < Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr > < AMA / HyperView Systems Home: 401-846-7639 > < 28 Jacome Way Work: 401-849-9930 x301 > < Middletown, RI 02840 "If I just had a little more time...">
Gary_D_Walborn@cup.portal.com (05/22/88)
HELP!!!! I am using an Amiga 2090 controller with a SCSI drive manufactured
for the Mac. When I format the drive everything appears normal. The format
program runs to completion with no mention of errors. If I run a program to
check for bad blocks at this point I get no indication of bad blocks. (BTW,
this drive has automatic (i.e. transparent) handling of bad blocks.) The
disk icon appears normally and I can read and write to the drive. Then....
when I use the drive, I will eventually get a 'Read/Write Error' requestor
for this disk. A disk sector editor will refuse to read the sector in
error. In addition, if the 'bad block' checker is run once I have used the
drive for a while, it shows a large number of bad blocks. Once those blocks
are removed by the 'bad block' remover, the disk often becomes 'Corrupted' and
the system will refuse to use that disk.
It seems that there is something very significant happening here! Are then
there major bugs in the SCSI portions of hddisk? What is happening?cmcmanis%pepper@Sun.COM (Chuck McManis) (05/23/88)
A word of warning. SCSI Drives that are targeted for the Mac are formatted
with 532 byte sectors. This will screw up amigaDOS which is expecting 512
bytes sectors. The solution is to send the SCSI 'mode' command to the drive
and tell it to use 512 byte sectors and then hard format it.
--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.jesup@cbmvax.UUCP (Randell Jesup) (05/24/88)
In article <5748@cup.portal.com> Gary_D_Walborn@cup.portal.com writes: >HELP!!!! I am using an Amiga 2090 controller with a SCSI drive manufactured >for the Mac. When I format the drive everything appears normal. The format ... >when I use the drive, I will eventually get a 'Read/Write Error' requestor >for this disk. A disk sector editor will refuse to read the sector in >error. In addition, if the 'bad block' checker is run once I have used the >drive for a while, it shows a large number of bad blocks. Once those blocks >are removed by the 'bad block' remover, the disk often becomes 'Corrupted' and >the system will refuse to use that disk. It sounds like these utilities you're using are Mac utilities, and they think something has wiped sectors (because AmigaDos has written to them.) When they remove the sectors, of course this will confuse AmigaDos. Tell it to use 512 bytes sectors (if you can), re-prep it (i.e. do a low level SCSI format), then reformat (amigados) the partitions, and try again. It's possible that you've told it the drive has more sectors (tracks * heads * blocks/track) than it has after bad-block mapping. If the previous fails, try reducing the number of cylinders you say it has. Randell Jesup {uunet|ihnp4|allegra}!cbmvax!jesup
peter@sugar.UUCP (Peter da Silva) (06/01/88)
In article <2762@umd5.umd.edu>, louie@trantor.umd.edu (Louis A. Mamakos) 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. > You're wrong. Thanks for starting out with a nice solid slam. It really helps make people take your arguments seriously when the first thing you say is "You're wrong". > The device driver (or on-board microcode) for the A2090 > controller does this. Why add needless complexity to the file handler > when the device driver know how to do this better? Why have the exact same code sitting there in expensive EPROM on every disk controller instead of centralising it in one place. > And if you're > fortunate, the disk controller or the drive (e.g. SCSI drives) will do > the bad block management for you. I'm not fortunate, then. I don't have a scuzzy drive. I have two 3.5" microfloppies. Their driver is trackdisk.device. It doesn't do it for me. The file system doesn't do it for me. What am I supposed to do? Buy three times as many disks and keep lots of backups. That's what. > >> Let the driver present a perfect pack to > >> the file system. Then how about putting it into the goddamn floppy drivers. OK, let's try this another way. Commodore: practice what you preach and put bad block handling in trackdisk.device. It's gotta be somewhere... the current situation is just not acceptable. > I can't understand why everyone seems to have problems with floppy disks. > Between my A1000 that I had for 2.5 years (since day 0), and the A2000 > I've had since then, I've only had 2 or 3 disks ever crap out on me out of > literally hundreds. Maybe I just live right or something. You're just lucky, I guess. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
sterling@cbmvax.UUCP (Rick Sterling QA) (06/02/88)
In article <2070@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > In article <2762@umd5.umd.edu>, louie@trantor.umd.edu (Louis A. Mamakos) writes: > > > I can't understand why everyone seems to have problems with floppy disks. > > Between my A1000 that I had for 2.5 years (since day 0), and the A2000 > > I've had since then, I've only had 2 or 3 disks ever crap out on me out of > > literally hundreds. Maybe I just live right or something. > > You're just lucky, I guess. It might be instructive to compare what brand of floppies you folks are using... I've found that the high quality ( expen$ive ) DSDD types seem to be nearly indistructable... where the bargain basement 'no-name' ones yeild about ~20% failure rate. ============================================================================= Rick Sterling COMMODORE AMIGA TEST ENGINEERING // /_ |\/||/_ /_ UUCP ...{allegra,ihnp4,rutgers}!cbmvax!sterling \X/ / \| ||\// \ PHONE 215-431-9275 ============================================================================= Everybody likes hard work ... especially when THEY'RE paying for it. =============================================================================
ejkst@cisunx.UUCP (Eric J. Kennedy) (06/06/88)
In article <3918@cbmvax.UUCP> sterling@cbmvax.UUCP (Rick Sterling QA) writes: > It might be instructive to compare what brand of floppies you folks are > using... I use "Bargain basement" floppies from MEI/Micro or Direct Micro ($.99 and $1.19 in bulk, respectively, I think.) I would estimate a failure rate of <4%. I have had much worse luck with more expensive disks. (this is out of a total inventory of about 250 disks, 2/3 of which are the cheap ones.) -- ------------ Eric Kennedy ejkst@cisunx.UUCP
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (06/06/88)
In article <2070@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >I'm not fortunate, then. I don't have a scuzzy drive. I have two 3.5" >microfloppies. Their driver is trackdisk.device. It doesn't do it for me. >The file system doesn't do it for me. What am I supposed to do? Buy three >times as many disks and keep lots of backups. That's what. > Or you could try hunting down reliable media. I have almost never had a problem with *my* drives (no consolation to you, I know). I make a point, whenever I can, of avoiding a disk that isn't made in Japan, that isn't blue, and that is made by Verbatim. When buying a batch of floppies, open the door and look at a reflection of a light source on the media surface. It should be very shiny, not dull, hazy, or "frosted" in any way, and should not have any regular patterns on it (like parallel lines). It should be perfectly smooth. If a dealer won't let you examine the media before purchasing it, point your nose in the air and go elsewhere. And of course, only buy certified DS-DD media. >Then how about putting it into the goddamn floppy drivers. OK, let's try >this another way. Commodore: practice what you preach and put bad block >handling in trackdisk.device. It's gotta be somewhere... the current situation >is just not acceptable. > Someone from Commodore explained sometime back (rather well, I thought) that bad *block* handling cannot be integrated into the trackdisk.device because of the way it reads and writes tracks. It does not observe the start-of-track marker. When asked to perform a write, it merely starts blasting bits onto the media. It is up to the read routine to figure out which sectors are which. The upshot of this is that, since a disk write can start anywhere, sectors move around the physical track. Hard errors are more or less stationary. Therefore, from write to write, an error will seem to move from sector to sector. The only way to get around this is to have the trackdisk.device perform bad *track* mapping. However, that can become expensive in terms of disk space. I'm also not sure if it is feasable or whether the benefits would outweigh the costs of putting the feature in (and thereby introducing another level of incompatibility). P.S: I've put a new quote in my .signature for as long as I find it amusing. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Hmm, you're right. Air is made up of suspended meat loaf." -- Josh Siegel
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (06/07/88)
In article <6180@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > The only way to get around this is to have the trackdisk.device > perform bad *track* mapping. However, that can become expensive in terms of > disk space. I'd much rather have the trackdisk.device perform bad track mapping than just ignore media problems altogether. Sure, excluding bad tracks wastes a lot of disk space. But I'd rather lose a whole track because one sector is defective than have the entire disk or file be unreadable. Certainly the format program should identify bad tracks and lock them out. Media failures are a fact of life. It's entirely unreasonable to ignore them and tell everyone to buy better disks. I only use Sony DS-DDs but I still want AmigaDOS to check the media during formatting. And I want bad tracks to be locked out when they are identified so I don't lose valuable data by writing to them. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
louie@trantor.umd.edu (Louis A. Mamakos) (06/07/88)
In article <410@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > I'd much rather have the trackdisk.device perform bad track mapping >than just ignore media problems altogether. Sure, excluding bad tracks >wastes a lot of disk space. But I'd rather lose a whole track because one >sector is defective than have the entire disk or file be unreadable. > > Certainly the format program should identify bad tracks and lock them >out. Media failures are a fact of life. It's entirely unreasonable to >ignore them and tell everyone to buy better disks. I only use Sony DS-DDs >but I still want AmigaDOS to check the media during formatting. And I want >bad tracks to be locked out when they are identified so I don't lose >valuable data by writing to them. While I agree that bad block mapping be done in the disk device driver, I really think that its overkill for a $2 piece of media. Is it really worth the trouble? Save some grief and just throw it away. I think that the point of diminishing return has been passed. Unless you designate a reserved track on *EACH AND EVERY* floppy disk that you format, you won't be able to DISKCOPY from one floppy to another. I use Sony DS/DD, 3M DS/DD and BASF DS/DD. In blue, black and tan colors. I don't have to toss very many of them at all. Do you really want Commodore/Amiga to spend time screwing with a working trackdisk.device, or doing something more productive? Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
geoffo@elecvax.eecs.unsw.oz (Geoff Oakley) (06/08/88)
In case this opinion has not yet been posted.
I am not particularly concerned about sophisticated bad block handling
for floppies, but I do want to know about bad block when it is still
possible to recover from errors. This is at time of write, not two weeks
later when I try to read it (and it was my only backup).
To this end, when I am copying disks I use a program that does a verify,
such as Tom Rokicki's DFC (thanks Tom), rather than diskcopy which
seems to write on regardless.
When copying files I am less happy. It seems that copy does not do a
read after write check, so if it is important I try to remember to copy
the new file to nil: as a manual verify.
Now my own `bad block hadling plea'.
I would like anything that writes to disk to do a read after write test
(possibly optionally, but what cost safety). Possibly this could be
done simply in trackdisk.device, is it not just spinning the disk round
once more?
I apologise to copy and/or trackdisk.device if this already happens,
but several lost backup files make me cautious.
Geoff Oakley Telephone:
School of EE and CS +61 2 697 4043
University of NSW Network mail:
PO Box 1 ACSNet: geoffo@elecvax.oz
Kensington NSW 2033 UUCP: {{uunet, hplabs, ubc-vision, mcvax, enea, ukc,
AUSTRALIA prlb2}!munnari, decvax!mulga}!elecvax.oz!geoffothad@cup.portal.com (06/09/88)
Mapping out bad sectors OR tracks on a 3.5" floppy is ludicrous. SONY (among others) has a media guarantee; if you have a bad disk, SONY will replace it. It is paramount for the FORMAT to identify a bad disk so one doesn't use it. If, in fact, you had a bad-track-mapped-out disk, thus giving you a 159 track disk (instead of the "normal" 160 tracks (80 cyls x 2), I would like to know what you would expect a program such as DISKCOPY to do when attempting to copy, say, a 160-track disk onto a 159-track disk? A bad floppy should be tossed out the window and over the fence if the manufacturer cannot replace it with a good one (within the warranty period).
tlm@pur-phy (Timothy Lee Meisenheimer) (06/10/88)
In article <2268@antique.UUCP> vax135!cjp (Charles Poirier) writes: >Fixing a gaping hole in data security is plenty productive. >Besides, this seems like a relatively easy thing to program. Hey, couldn't we just mark all the disks in that bad track as allocated but not to anything in particular? I'm not sure what would happen when you did a diskcopy - probably just leave you with a useless track.
peter@sugar.UUCP (Peter da Silva) (06/14/88)
In article <6180@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > In article <2070@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >I'm not fortunate, then. I don't have a scuzzy drive. I have two 3.5" > >microfloppies. Their driver is trackdisk.device. It doesn't do it for me. > >The file system doesn't do it for me. > I make a point, whenever I can, of avoiding a disk that isn't made in > Japan, that isn't blue, and that is made by Verbatim. You're not married, are you? I've had expensive floppies and cheap floppies go bad on me. Floppies go bad. Particularly in an environment that contains a two-year-old child, a cat, and a smoker. I can't do anything about that. Despite what some people may think, my computer *isn't* more important than my family. ANYWAY, the point still remains that the Amiga's handling of errors is a complete disgrace. I can't really push it as hard as I can without a reliable disk drive *out of the box*. Other computers can operate in the face of imperfect media. > >Commodore: practice what you preach and put bad block handling in > >trackdisk.device. It's gotta be somewhere... the current situation > >is just not acceptable. > Someone from Commodore explained sometime back (rather well, I > thought) that bad *block* handling cannot be integrated into the > trackdisk.device because of the way it reads and writes tracks. Leo, do you really think I'm that dense? When I say "block" I'm talking about the basic unit of I/O. Not an imaginary sector that only exists in the minds of the Commodore programmers. The trackdisk.device "disk block" is 5.5K long and fills a track. > The only way to get around this is to have the trackdisk.device > perform bad *track* mapping. Or have the file system recognise that it's not dealing with perfect media. Here's a case where the FS can definitely do something that the driver can't: mark that track as read-only and use it as a copy-on-write cache. There are *lots* of such optimisations that the FS can do. Or blow off compatibility altogether and go to a sane file system like UNIX's. With inodes, fast directory searches, and so on. When you wish upon a star... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.