From owner-freebsd-fs@FreeBSD.ORG Thu Sep 26 06:12:12 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 400E97AA; Thu, 26 Sep 2013 06:12:12 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 198032E40; Thu, 26 Sep 2013 06:12:12 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r8Q6C7kj086301; Wed, 25 Sep 2013 23:12:07 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201309260612.r8Q6C7kj086301@chez.mckusick.com> To: lev@FreeBSD.org Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-reply-to: <138452559.20130925233248@serebryakov.spb.ru> Date: Wed, 25 Sep 2013 23:12:07 -0700 From: Kirk McKusick Cc: freebsd-fs , Jeff Roberson X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 06:12:12 -0000 > Date: Wed, 25 Sep 2013 23:32:48 +0400 > From: Lev Serebryakov > To: Kirk McKusick > CC: Jeff Roberson , > freebsd-fs > Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. > > Hello, Kirk. > You wrote 23 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= > 2:24:02: > > > KM> Have you run a manual (fsck -f) on the affected filesystems? If so, > KM> was it able to clean them up? If not, please do so and save the output > KM> of fsck (using script command is usually the easiest way to do this). > I've stopped server and checked two FSes with WTITE errors (/ and /usr) > with fsck -f, but it didn't find any errors at all. > I have / dumped (completely, as binary blob) and could upload it when I > find and mask all passwords :) > > --=20 > // Black Lion AKA Lev Serebryakov I do not think that we are likely to find out anything useful from looking at your dumpped /. Notably the errors that were produced were because an indirect block had gottened trashed. Looking at the file image is not going to tell us how they got trashed. Usual cases are memory errors, address line errors on the I/O bus, or I/O error in the disk itself. The journal does not know of these errors, so does not look to correct them. Hence the need for a manual fsck. Kirk McKusick