Date: Fri, 06 Jul 2001 09:03:54 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/etc diskcheckd.conf Message-ID: <15237.994403034@critter> In-Reply-To: Your message of "Fri, 06 Jul 2001 15:25:26 %2B1000." <20010706152526.C506@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010706152526.C506@gsmx07.alcatel.com.au>, Peter Jeremy writes: >On 2001-Jul-06 06:30:36 +0200, Poul-Henning Kamp <phk@critter.freebsd.dk> wrote: >>diskcheckd is not designed or intended to do scrubbing, its goal has >>been reached if it does detection. > >The only problem is that soft errors won't be detected until they >become hard errors - which is too late for the data on the disk. >diskcheckd seems to be a slow (non I/O intensive) way to run >"dd if=/dev/foo of=/dev/null bs=64k". It would be useful if the >disk drivers could report soft errors so that something like >diskcheckd could detect that a disk was going bad whilst it was >still readable. Even if we only see them when they've become hard errors, I still consider it a good thing to notice as early as possible. Yes, if we can improve on diskcheckd I think we should, it may take the cooperation of the driver writers to get a "tell me about any soft errors too" ioctl implemented, but for now, just noticing that a disk is going south is a fair step forward. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15237.994403034>