From owner-freebsd-hackers Fri Feb 6 07:01:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA23476 for hackers-outgoing; Fri, 6 Feb 1998 07:01:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA23462 for ; Fri, 6 Feb 1998 07:01:11 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id KAA27827; Fri, 6 Feb 1998 10:02:18 -0500 From: Bill Paul Message-Id: <199802061502.KAA27827@skynet.ctr.columbia.edu> Subject: Re: wd0s1e hard errors To: cgull+usenet-886763413@smoke.marlboro.vt.us (john hood) Date: Fri, 6 Feb 1998 10:02:17 -0500 (EST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199802061118.GAA08425@smoke.marlboro.vt.us> from "john hood" at Feb 6, 98 06:18:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" 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. 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. It just makes my teeth itch. The Linux people keep throwing stuff in, and we keep throwing stuff out. 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. Do _not_ argue this point with me. I don't want to hear 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). 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. That's why format(8) exists. (Ditto fx(8) in SGI IRIX, which is similar to format in function, if not in appearance.) If you really want to force a disk to add a block to its defect list, you should be able to, without resorting to voodoo like 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?) 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.) 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. - 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. - No, there should not be a GUI interface. There should be a standard console interface and a _stellar_ manual page. - 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. 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. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================