Date: Sat, 07 Feb 1998 07:16:48 -0800 From: Mike Smith <mike@smith.net.au> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: cgull+usenet-886763413@smoke.marlboro.vt.us (john hood), hackers@FreeBSD.ORG Subject: Re: wd0s1e hard errors Message-ID: <199802071516.HAA00796@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 06 Feb 1998 10:02:17 EST." <199802061502.KAA27827@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Of all the gin joints in all the towns in all the world, john hood had > to walk into mine and say: > > > Tony Kimball writes: > > > > > > Should bad144 be retired? > > > > Yup, from current, anyway. > > No. It should not. Are you willing to wear the "bad144 maintainer's hat"? If you aren't, then swallow your pride and live with the fact that it's going to die. > I'm getting _really_ tired of people pointing their fingers at bits > of code and saying: "Oh well, we don't have enough time/resources/brains > to maintain this and I can tell thanks to my vast psychic powers that > nobody's using it anyway, so let's just chop it out of the tree and > throw it away." It happend with the 'unused' networking protocols, > it happened with LFS, and now it's happening with bad144. And IMHO that's not half bad. The unused protocols died because nobody gave a stuff about looking after them. Likewise LFS (which never worked in the first place), and bad144 is very close to both. > It just makes my teeth itch. The Linux people keep throwing stuff in, > and we keep throwing stuff out. FreeBSD is not a nightsoil cart. > I'll tell you when you can get rid of it: when the last MFM/RLL/ESDI > disk sputters and explodes in a blaze of glory, and not before. As long > as there's still _one_ person out there who might find it useful, it > stays. Sure. As long as this one person is willing to look after it. As long as this one person is willing to handle the support complaints from the dozens or hundreds of people that stupidly use bad144 on disks or partitions for which it is either inappropriate or completely broken. > Do _not_ argue this point with me. I don't want to hear it. Then you message was pointless. You're inviting discussion on the matter, and taking a stance. You've gone further and put your foot damn well *in* it. > Instead of ripping stuff _out_ of the system, why doesn't somebody > work on putting something in. You know what would be really nice to > have? A utility like format(8) from SunOS (and even Solaris). Oh yes. Sure. All that format(8) actually does that's useful is currently covered by scsiformat(8) and disklabel(8). We have fdisk(8) for some extra stuff that Suns don't have to deal with. Never mind that format(8) will nuke the firmware on a number of Seagate disks, or that Quantum disks without the Sun OEM firmware reject the format command. Or that it uses static information on your disk out of a table maintained at best erratically. If you really want a tool like this, I suggest you extract the digit of your choice and port sformat. It's significantly better, and waiting for your free time and loving attention. I'd certainly appreciate not having to write scsi(8) command strings by hand;. > For > those who don't know, format(8) is a general purpose disk utility > that lets you label disks, perform media analysis on them, reformat > them (if you absolutely have to) and _update_ _a_ _disk's_ _own_ > _defect_ _list_. Are disks _always_ smart enough to spare out bad > blocks on their own? Not in my experience. If you set the ARRE/AWRE bits in the mode page (example in the scsi(8) manpage, BTW), and the disk is in a position to guarantee no data loss (either read recovery via ECC or a write failure), then yes, they do. I have (fortunately) verified this on quite a number of units. Agreed, having a tool to manipulate the sparing map on a disk would be nice, but you can do that with Tcl and scsi(8). > Now, duplicating the SunOS format command in FreeBSD isn't all that > easy. For one thing, it needs some device-specific knowledge in order > to be able to do low-level things like initiate a low-level format, > analyze media, or manipulate the bad block list. Plus, it must be > made to work with all supported kinds of r/w disk (SCSI, IDE, floppies, > and other removable media. I don't know that all supported disk controllers > have a nice consistent interface for allowing this. (Maybe libdisk?) You have got to be joking. You can't perform format operations on ATA disks, you can't manipulate their sparing data in any fashion, you can't really do anything other than read and write them. Floppy disks are about to go the same way (viz. ATAPI floppy units), and to be quite honest I can't imagine too many people that give a toss about media perfection on a floppy; if it has a bad sector, bin it. > Also, back when people used to install SunOS 4 from tape, I think there > used to be a standalone version of format used for labeling a disk so > that the installation miniroot image could be loaded from tape onto disk > and booted. Making a standalone program like this for FreeBSD is next to > impossible due to all the required device support: Sun workstations > typically have a limited number of disk controllers; PCs have dozens, if > not more. (Besides, we don't even have a libsa. There's another thing we > could use! OpenBSD even has one somebody could copy. Hint hint.) It was stolen from NetBSD. Have you ever tried porting it? I'd love a copy, please. (Hint, it's almost inextricably intertwined with the kernel, and they have some neat but mutant makefile constructs that make building it an extreme nuisance. In addition, it's loaded using a hardcoded blockmap out of the bootblock, meaning that you can't pull a bootblock off a floppy and boot from any disk.) > A few quick shots to stop people muddying this idea with tangential > discussions: > > - No, the scsi(8) command is not a replacement for format(8). scsi(8) > is only useful for people with SCSI mode page data tattooed on their > brains. Sure. It's a backend useful for scripts. It saves you all your whining about needing to know how to talk to individual devices by letting you look the stuff up in the SCSI documentation, which is nice and easy. > - No, a wrapper around scsi(8) isn't good enough either. scsi(8) is > only for SCSI. A properly written format(8) should handle _all_ > disk types. As previously observed, you can't format (or anything else) any other media types. (Except for the WD1003 clones where formatting can only be managed by the firmware on the card, and floppies which already have a format tool of their own.) > - No, creating a format(8) does _NOT_ mean that you can throw out > other utilities like disklabel(8) and fdisk(8). Why? Because > people use FreeBSD for learning. If I want to know how to disklabel > a disk, looking at the format(8) source might take too long, whereas > disklabel(8) is smaller and simpler. disklabel is a backend. > So, anybody up to this? It would be a nice change of pace to see somebody > add some useful low-level functionality to the system instead of taking it > away. I'm not in a position to answer that just yet; I need to talk to Julian E. about the slice stuff. But yes, it matters a great deal to me. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802071516.HAA00796>