From owner-freebsd-fs@FreeBSD.ORG Wed Mar 6 07:32:55 2013 Return-Path: Delivered-To: freebsd-fs@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 94015FC0; Wed, 6 Mar 2013 07:32:55 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 58F607A9; Wed, 6 Mar 2013 07:32:55 +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 3CB884AC58; Wed, 6 Mar 2013 11:32:53 +0400 (MSK) Date: Wed, 6 Mar 2013 11:32:50 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1644513757.20130306113250@serebryakov.spb.ru> To: Don Lewis Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: <201303060715.r267FDHS015118@gw.catspoiler.org> References: <612776324.20130301152756@serebryakov.spb.ru> <201303060715.r267FDHS015118@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-5 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.org, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org 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: Wed, 06 Mar 2013 07:32:55 -0000 Hello, Don. You wrote 6 =DC=D0=E0=E2=D0 2013 =D3., 11:15:13: DL> Did you have any power failures that took down the system sometime DL> before this panic occured? By default FreeBSD enables write caching on I had other panic due to my inaccurate hands... But I don't remeber any power failures, as I havee UPS and this one works (I check it every month). DL> That means that the drive will immediately acknowledge writes and is DL> free to reorder them as it pleases. DL> When UFS+SU allocates a new inode, it first clears the available bit in DL> the bitmap and writes the bitmap block to disk before it writes the new DL> inode contents to disk. When a file is deleted, the inode is zeroed on DL> disk before the available bit is set in the bitmap and the bitmap block DL> is written. That means that if an inode is marked as available in the DL> bitmap, then it should be zero. The system panic that you experienced DL> happened when the system was attempting to allocate an inode for a new DL> file and when it peeked at an inode that was marked as available, it DL> found that the inode was non-zero. DL> What might have happened is that sometime in the past, the system was in >[SKIPPED] DL> tried to allocate the inode in question. This scenario looks plausible, but it raises another question: does barriers will protect against it? It doesn't look so, as now barrier write is issued only when new inode BLOCK is allocated. And it leads us to my other question: why did not mark such vital writes with flag, which will force driver to mark them as "uncacheable" (And same for fsync()-inducted writes). Again, not BIO_FLUSH, which should flush whole cache, but flag for BIO. I was told my mav@ (ahci driver author) that ATA has such capability. And I'm sure, that SCSI/SAS drives should have one too. --=20 // Black Lion AKA Lev Serebryakov