Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Jul 2009 23:32:05 +0200
From:      Ivan Voras <ivoras@freebsd.org>
To:        freebsd-fs@freebsd.org
Subject:   Re: geom_mirror/UFS weirdness with 7.2-STABLE
Message-ID:  <h42nos$buu$1@ger.gmane.org>
In-Reply-To: <4A646DA8.2050201@acm.poly.edu>
References:  <4A646DA8.2050201@acm.poly.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]
Boris Kochergin wrote:
> Ahoy. I noticed some very odd things in my file server's kernel buffer
> this morning (there were actually a ton of these--this is a snippet):
> 
> Jul 20 05:54:10 exodus smartd[763]: Device: /dev/ad1, FAILED SMART
> self-check. BACK UP DATA NOW!
> Jul 20 05:57:57 exodus kernel:
> g_vfs_done():mirror/boots1[READ(offset=-4569735194538825728,
> length=16384)]error = 5
> Jul 20 05:57:57 exodus kernel: bad block 8806809555123731765, ino 4430620
> Jul 20 05:57:57 exodus kernel: pid 35 (softdepflush), uid 0 inumber
> 4430620 on /: bad block

> 
> # df /
> Filesystem         1K-blocks                 Used               Avail
> Capacity  Mounted on
> /dev/mirror/boots1  37846636 -4058799239201906816 4058799239236725722
> -11656883301279%    /
> 
> The system is a:
> 
> # uname -a
> FreeBSD exodus.poly.edu 7.2-STABLE FreeBSD 7.2-STABLE #3: Sat Jul 11
> 16:22:02 EDT 2009     root@exodus.poly.edu:/usr/obj/usr/src/sys/EXODUS 
> amd64
> 
> Regarding smartd yelling at me about /dev/ad1, it's been doing that for
> long while before this. There is one sector on the drive that cannot be
> read, but the disk has otherwise been fine for months. My experience
> with geom_mirror has been that it disconnects members from an array if
> they experience I/O errors, so this seems to be something different. Any
> clues?

It looks like the drive returned corrupted data without returning an
error - which is strange, but not impossible. You are probably seeing
numbers like -4058799239201906816 because some metadata is corrupted. If
so, you should immediately disconnect the problematic drive so that the
errorneous data isn't picked up and written to the good drive.



[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpk4lUACgkQldnAQVacBcg9YgCg4gENDmV+VS0OePXe/bglQSle
iOEAoK3LBtdXGaOXBTwbwb3YF3v8+G5h
=Grl1
-----END PGP SIGNATURE-----

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?h42nos$buu$1>