From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 12:18:22 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 678B3A6C; Mon, 23 Sep 2013 12:18:22 +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 26B4C27DF; Mon, 23 Sep 2013 12:18:21 +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 CBF6B4AC59; Mon, 23 Sep 2013 16:18:14 +0400 (MSK) Date: Mon, 23 Sep 2013 16:18:10 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1064796147.20130923161810@serebryakov.spb.ru> To: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-Reply-To: <0AA0A9CE-C692-4183-94FA-BC43837ADAE3@FreeBSD.org> References: <724152380.20130921144811@serebryakov.spb.ru> <0AA0A9CE-C692-4183-94FA-BC43837ADAE3@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs , Kirk McKusick 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: Mon, 23 Sep 2013 12:18:22 -0000 Hello, Edward. You wrote 23 =F1=E5=ED=F2=FF=E1=F0=FF 2013 =E3., 2:43:23: ETN> According to "man errno", 22 is EINVAL. Which is... weird, to say the= least. ETN> What's below the filesystem? I mean, what's the GEOM tree? It is typical for old-skool installation, with addition of UFS labels: ada0 -MBR-> ada0s1 -BSD LABEL-> ada0s1[abdef]. Moutns are via UFS labels (not glabel!) ufs/root =3D=3D ada0s1a ufs/var =3D=3D ada0s1d ufs/tmp =3D=3D ada0s1e ufs/usr =3D=3D ada0s1f /dev/ufs/root on / (ufs, local, soft-updates) /dev/ufs/tmp on /tmp (ufs, local, journaled soft-updates) /dev/ufs/usr on /usr (ufs, NFS exported, local, journaled soft-updates) /dev/ufs/var on /var (ufs, local, journaled soft-updates) Swap is configured via glabel label/swap =3D=3D ada0s1b >> (2) How to avoid fsck refuses in such situations? Why OTHER (not ones wi= th >> write errors) FSes get errors? It looks like one another problem with SU= +J. ETN> Try to make fsck _not_ use journal. Simply respond "n" when it asks i= f you want ETN> it to use journal. /usr and /tmp were fixed by _not_ using journal, when I see that server g= oes to single-user mode. /var and / were fixed before that by fsck runs on boot sequence after this panic, so I leave them as-is, because, I didn't know about write errors at this moment... >> Please note, these FSes reside directly on SATA drive, without any softw= are or >> hardware RAIDs. ETN> No labels, for example? See above. --=20 // Black Lion AKA Lev Serebryakov