From owner-freebsd-fs@FreeBSD.ORG Thu Sep 26 11:46:59 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8E195A06 for ; Thu, 26 Sep 2013 11:46:59 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4CDF824FE for ; Thu, 26 Sep 2013 11:46:58 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5b:71c5:b3bc:c366]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id ECFE74AC57; Thu, 26 Sep 2013 15:46:54 +0400 (MSK) Date: Thu, 26 Sep 2013 15:46:47 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1537848823.20130926154647@serebryakov.spb.ru> To: Kirk McKusick Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-Reply-To: <201309260612.r8Q6C7kj086301@chez.mckusick.com> References: <138452559.20130925233248@serebryakov.spb.ru> <201309260612.r8Q6C7kj086301@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs , Jeff Roberson X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 11:46:59 -0000 Hello, Kirk. You wrote 26 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= 10:12:07: KM> I do not think that we are likely to find out anything useful from KM> looking at your dumpped /. Notably the errors that were produced were KM> because an indirect block had gottened trashed. Looking at the file KM> image is not going to tell us how they got trashed. Usual cases are KM> memory errors, address line errors on the I/O bus, or I/O error in the KM> disk itself. The journal does not know of these errors, so does not KM> look to correct them. Hence the need for a manual fsck. Kirk, I want to bring into focus, that EINVAL writes were seen for / and /var (which leaded to panic and reboot), and fsck after panic failed for /u= sr and /tmp. So, you words "The journal does not know of these errors, so does not look to correct them." is not belong here. Journal was unable to correct errors on FSes which didn't have any problems at moment of panic! And after all, full fsck didn't find any problems with indirect blocks on / and /var later (yesterday). I repeat again: journal problems were seen on filesystems, which didn't have any visible problems at moment of panic. --=20 // Black Lion AKA Lev Serebryakov