Date: Sun, 27 Feb 2000 13:09:28 +1030 (CST) From: kibbet <kib@knfpub.com> To: freebsd-current@freebsd.org Subject: Re: bad blocks Message-ID: <XFMail.000227130928.kib@knfpub.com> In-Reply-To: <Pine.BSF.4.21.0002261301540.43802-100000@gateway.posi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi again, On 26-Feb-00 Kelly Yancey wrote: > On Sun, 27 Feb 2000, kibbet wrote: > >> Hi all, >> >> Quick question, how does the new ata driver handle bad blocks? >> I've been tracking -current since around Nov 99 but haven't >> seen this come up. > > As I recall, it doesn't. The reasoning is that modern IDE drives perform bad > block reassignment so if you are seeing bad block errors, then the entire > reserve of blocks available for reassignment has been exhausted. In which > case, things are Very Bad and you should start backing up your data ASAP. Yup, no problem, sounds fair. Just read the docs for this drive, it dosent say anything about bad blocks, but its only a few years old so I'm assuming it does the fancy bad block assignment. :) (its an IBM DJAA-31700) No need to backup, I keep it around for this specific reason :) > In you scenario of upgrading from the old wd driver in -stable to the new ad > driver in -current, the only advisable action is to just not do a bad block > scan under -stable before upgrading. The should stop the complaints from the > ad driver about the old-style bad block table. The new ad driver dosen't seem to complain at all if I've bad block scanned when installing -stable (infact I can't install -stable if I haven't block scanned the drive). The (-current) ad and wd drivers just seem to ignore the fact the drive had been scanned. The problem arises when I use bad144 on -current, rather than just complaining it actually makes the system unbootable. eg.; freebie4# bad144 -s -v ad0 cyl: 3307, tracks: 16, secs: 63, sec/cyl: 1008, start: 0, end: 3334212 bad144: couldn't set disk in "badscan" mode: Operation not supported by device Block: 1202131 will be marked BAD. [snip more blocks marked BAD] Then I reboot, and I get; ad0: bad sector table not supported So this raises a few questions; 1: Should bad144 exit without doing anything if it detects a modern drive that handles its own bad blocks? 2: Should the process of mounting root ignore bad144 info if the drive does its own bad blocks? IMHO one of the above should happen, you shouldn't be left with an unmountable root because you ran bad144 on a drive that dosen't support it. 3: Is it possible (or advisable) to use badd144 info in conjunction with the drives bad block data? (I've got 21 bad blocks on this drive, which haven't grown since they appeared, I'd like these blocks to be ignored) - I guess this would be rather more than just a trivial task :) 4: The $6m question, how do I fix it so I can mount root? :) I have a generic -stable kernel (so I think I can boot), but I can't find any mention of how to tell the drive not to use bad144 info. Anyways, abuse away if I've totally missed the plot :) Cheers, Kent Ibbetson kib@knfpub.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.000227130928.kib>