Date: Sun, 14 Dec 1997 10:42:51 +1030 From: Greg Lehey <grog@lemis.com> To: Julian Elischer <julian@whistle.com> Cc: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG Subject: Re: DEVFS: new sample code Message-ID: <19971214104251.63209@lemis.com> In-Reply-To: <Pine.BSF.3.95.971212104644.28515D-100000@current1.whistle.com>; from Julian Elischer on Fri, Dec 12, 1997 at 10:59:32AM -0800 References: <199712121837.FAA00920@godzilla.zeta.org.au> <Pine.BSF.3.95.971212104644.28515D-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971214104251.63209>