From owner-freebsd-geom@FreeBSD.ORG  Fri Mar  1 11:28:20 2013
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id C279F497;
 Fri,  1 Mar 2013 11:28:20 +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 82D62854;
 Fri,  1 Mar 2013 11:28:20 +0000 (UTC)
Received: from lion.home.serebryakov.spb.ru (unknown
 [IPv6:2001:470:923f:1:9421:367:9d7d:512b])
 (Authenticated sender: lev@serebryakov.spb.ru)
 by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 9F5BE4AC59;
 Fri,  1 Mar 2013 15:28:02 +0400 (MSK)
Date: Fri, 1 Mar 2013 15:27:56 +0400
From: Lev Serebryakov <lev@FreeBSD.org>
Organization: FreeBSD
X-Priority: 3 (Normal)
Message-ID: <612776324.20130301152756@serebryakov.spb.ru>
To: Ivan Voras <ivoras@freebsd.org>, Don Lewis <truckman@FreeBSD.org>
Subject: Re: Unexpected SU+J inconsistency AGAIN -- please,
 don't shift topic to ZFS!
In-Reply-To: <kgo2hn$f1s$1@ger.gmane.org>
References: <1796551389.20130228120630@serebryakov.spb.ru>
 <1238720635.20130228123325@serebryakov.spb.ru>
 <1158712592.20130228141323@serebryakov.spb.ru>
 <CAPJF9w=CZg_+K7NHTGUhRLaMJWWNOG7zMipGMJL6w6NoNZpSXA@mail.gmail.com>
 <583012022.20130228143129@serebryakov.spb.ru> <kgnp1n$9mc$1@ger.gmane.org>
 <1502041051.20130228185647@serebryakov.spb.ru> <kgo2hn$f1s$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: lev@FreeBSD.org
List-Id: GEOM-specific discussions and implementations
 <freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-geom>,
 <mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
 <mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2013 11:28:20 -0000

Hello, Ivan.
You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 21:01=
:46:

>>   One time, Kirk say, that delayed writes are Ok for SU until bottom
>>  layer doesn't lie about operation completeness. geom_raid5 could
>>  delay writes (in hope that next writes will combine nicely and allow
>>  not to do read-calculate-write cycle for read alone), but it never
>>  mark BIO complete until it is really completed (layers down to
>>  geom_raid5 returns completion). So, every BIO in wait queue is "in
>>  flight" from GEOM/VFS point of view. Maybe, it is fatal for journal :(
IV> It shouldn't be - it could be a bug.
   I understand, that it proves nothing, but I've tried to repeat
 "previous crash corrupt FS in journal-undetectable way" theory by
 killing virtual system when there is massive writing to
 geom_radi5-based FS (on virtual drives, unfortunately). I've done 15
 tries (as it is manual testing, it takes about 1-1.5 hours total),
 but every time FS was Ok after double-fsck (first with journal and
 last without one). Of course, there was MASSIVE loss of data, as
 timeout and size of cache in geom_raid5 was set very high (sometimes
 FS becomes empty after unpacking 50% of SVN mirror seed, crash and
 check) but FS was consistent every time!


--=20
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>