Date: Thu, 14 Feb 2008 15:03:30 -0600 From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: UFS2 corruption (RELENG_7, amd64) Message-ID: <20080214150330.bj28qojhko0w4kgw@www.wolves.k12.mo.us> In-Reply-To: <200802141958.m1EJwCoZ078516@lurza.secnetix.de> References: <200802141958.m1EJwCoZ078516@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Oliver Fromme <olli@lurza.secnetix.de>: ...snip... > # fsck -y /dev/da45 > ** /dev/da45 > ** Last Mounted on [...] > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > UNALLOCATED I=3D2107428 OWNER=3D2283830233 MODE=3D0 > SIZE=3D0 MTIME=3DFeb 5 08:43 2008 > NAME=3D/D.0131ae2e/B.0786 > > UNEXPECTED SOFT UPDATE INCONSISTENCY > > REMOVE? yes I've been seeing "UNEXPECTED SOFT UPDATE INCONSISTENCY" fsck errors =20 show up in some of my filesytem snapshots on a RELENG_6 AMD64 box for =20 years (actually since RELENG_5), which will eventually lead to "panic: =20 snapblkfree: inconsistent block type" if those snapshots are mounted =20 and used. There are no SCSI or "bad block" errors or any error of any =20 other kind that shows up on my system before the problems occur. I =20 think I used default newfs settings when creating the (comparatively =20 small) 300GB filesystem. The problem happens rarely and on a =20 production system so I've never been able to pin it down to anything =20 in particular. I've found that others have seen the same panic, likely from the same cause: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/115645 (see first =20 reply in Audit-Trail) http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027916.html http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027917.html I did very recently determine that the "snapblkfree: inconsistent =20 block type" panic I see is due directly to the "soft update =20 inconsistency" in the snapshots, so there is some filesystem =20 corruption happening somewhere which leads to the panic later. I have =20 been regularly fscking the snapshots and deleting any of them that =20 have errors so they won't panic the system later. It has kept the =20 system panic-free for quite some time now. A commonality you will notice amongst all our systems is that they =20 are AMD64. I've been unable to find anyone having this problem on i386. --=20 Chris Dillon - NetEng/SysAdm Reeds Spring R-IV School District Technology Department 175 Elementary Rd. Reeds Spring, MO 65737 Voice: 417-272-8266 Fax: 417-272-0015
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080214150330.bj28qojhko0w4kgw>