From owner-freebsd-current Sat Dec 13 16:14:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26265 for current-outgoing; Sat, 13 Dec 1997 16:14:07 -0800 (PST) (envelope-from owner-freebsd-current) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26218 for ; Sat, 13 Dec 1997 16:13:12 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id KAA00889; Sun, 14 Dec 1997 10:42:52 +1030 (CST) (envelope-from grog) Message-ID: <19971214104251.63209@lemis.com> Date: Sun, 14 Dec 1997 10:42:51 +1030 From: Greg Lehey To: Julian Elischer Cc: Bruce Evans , current@FreeBSD.ORG Subject: Re: DEVFS: new sample code References: <199712121837.FAA00920@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: ; from Julian Elischer on Fri, Dec 12, 1997 at 10:59:32AM -0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Dec 12, 1997 at 10:59:32AM -0800, Julian Elischer wrote: > Disclaimer: > *this of course only applies to what I'm doing of course* > > It ain't going to get done there it's getting done in a layer just below, > and in conjunction with, the disk label layer. The disklabel layer notices > the bad144 flag and sticks the bad144 'wedge' below itself. the bad144 has > no business being lower than that because it doesn't cover other slices. > They may have their own badblock handlers. I don't understand why slices should have any notion of bad blocks. The way I see it, a slice is a virtual disk, and virtual disks are immaculate. Bad blocks are a fact of life of the dirty representations of our idealized disks. > it CERTAINLY doesn't get to be in the disk driver because THAT only > knows how to move blocks of data and how to propogate up error > reports. Still, it's the disk driver which should be maintaining problems on the disk. I (still!) haven't looked at the code, but wouldn't it be possible to teach the driver to propagate the errors? Greg