From owner-freebsd-current Sun Dec 14 00:30:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA21190 for current-outgoing; Sun, 14 Dec 1997 00:30:45 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA21184 for ; Sun, 14 Dec 1997 00:30:40 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA12834; Sun, 14 Dec 1997 00:21:18 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd012832; Sun Dec 14 00:21:14 1997 Date: Sun, 14 Dec 1997 00:18:36 -0800 (PST) From: Julian Elischer To: Greg Lehey cc: Bruce Evans , current@FreeBSD.ORG Subject: Re: DEVFS: new sample code In-Reply-To: <19971214104251.63209@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk sometimes we will be mounting filesystems off disks formatted by other systems. For those partitions we must obey hte bad-block hadling that they use or we will read garbage. a genenriv 'perfection' layer could of course be layered above any disk tht couldn't do it's own badblock mapping, or left of if it could, and even if it could, it may be used to resurect a diskk with more badblocks than teh manufacturer can handle. On Sun, 14 Dec 1997, Greg Lehey wrote: > 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 >