bad sector in gmirror HDD

[Jeremy Chadwick]

On Sun, Aug 21, 2011 at 02:00:33AM -0700, perryh at pluto.rain.com wrote:
> Jeremy Chadwick <freebsd at jdc.parodius.com> wrote:
> 
> > ... using dd to find the bad LBAs is the only choice he has.
> 
> or sysutils/diskcheckd.  It uses a 64KB blocksize, falling back to
> 512 -- to identify the bad LBA(s) -- after getting a failure when
> reading a large block, and IME it runs something like 10x faster
> than dd with bs=64k.
> 
> It would be advisable to check syslog configuration before using
> diskcheckd, since that is how it reports and there is reason to
> suspect that the as-shipped syslog.conf may discard at least some
> of diskcheckd's messages.

That software has a major problem where it runs constantly, rather than
periodically.  I know because I'm the one who opened the PR on it:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853

There's a discussion about this port/issue from a few days ago (how
sweet!):

http://lists.freebsd.org/pipermail/freebsd-ports/2011-August/069276.html

With comments from you stating that the software is behaving as designed
and that I misread the man page, but also stating point blank that
"either way the software runs continuously" (which is what the PR was
about in the first place):

http://lists.freebsd.org/pipermail/freebsd-ports/2011-August/069321.html

I closed the PR because when I left as a committer I no longer wanted to
deal with the issue.  I probably should have marked the PR as suspended,
but either way it's an ordeal that needs to get dealt with; it
absolutely should be re-opened in some way.

Then there's this PR, which I fully agree should have *nothing* to do
with gmirror, so I'm not even sure how to interpret what's written.
Furthermore, the author of this PR commented in PR 115853 stating
something completely different (read the first few lines very
carefully/slowly -- it seems to indicate he agrees with my PR, but then
opened up a separate PR with different wording):

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566

Back to my PR.

I state that I set up diskcheckd.conf using the option you describe as
"a length of time over which to spread each pass", yet what happened was
that it did as much I/O as it could (read the entire disk in 45 minutes)
then proceeded to do it again (no sleep()).  That is not the same thing
as "do I/O over the course of 7 days".

Furthermore, the man page example gives this:

   EXAMPLES
       To check all of /dev/ad0 for errors once every two weeks, use
       this entry in diskcheckd.conf:

             /dev/ad0        *       14      *

Which is no different than what I specified in my PR other than that I
used a value of 7 and the example uses 14.  So what about the rest of
the man page?

   The second format consists of four white space separated fields,
   which are the full pathname of the disk device, the size of that disk,
   the frequency in days at which to check that disk, and the rate in kilo-
   bytes per second at which to check this disk.  Naturally, it would be
   contradictory to specify both the frequency and the rate, so only one of
   these should be specified.  Additionally, the size of the disk should not
   be specified if the rate is specified, as this information is unneces-
   sary.

I did not misread the man page, especially given what's in EXAMPLES.
It's a bug somewhere -- either in the man page or the software itself.
This software will burn through your drive constantly, unless you use
the rate-in-kilobytes-per-second field.  The frequency field doesn't
work as advertised.

And besides, such a utility really shouldn't be a daemon anyway but a
periodic(8)-called utility with appropriate locks put in place to ensure
more than one instance can't be run at once.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |