From owner-freebsd-fs@FreeBSD.ORG Wed Mar 6 06:52:15 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 7C672FE9; Wed, 6 Mar 2013 06:52:15 +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 35E2262D; Wed, 6 Mar 2013 06:52:15 +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 843EF4AC57; Wed, 6 Mar 2013 10:52:07 +0400 (MSK) Date: Wed, 6 Mar 2013 10:52:05 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <958644234.20130306105205@serebryakov.spb.ru> To: Don Lewis Subject: Re: Panic in ffs_valloc (Was: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS!) In-Reply-To: <201303060643.r266hBWU015053@gw.catspoiler.org> References: <1352492388.20130302002244@serebryakov.spb.ru> <201303060643.r266hBWU015053@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-5 Content-Transfer-Encoding: quoted-printable Cc: mckusick@mckusick.com, freebsd-fs@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 06:52:15 -0000 Hello, Don. You wrote 6 =DC=D0=E0=E2=D0 2013 =D3., 10:43:11: DL> When growing a file, the data *must* be written before writing the block DL> pointer that points to it. If this ordering isn't obeyed, then a system DL> crash that occurs between the block pointer write and the data write DL> would result in the file containing whatever garbage was in the data DL> block. That garbage could be the confidential contents of some other DL> user's previously deleted file. It is why confidential data should be zeored-out before file deletion :) But here is another way: add "stream id" for all writes. FS could mark each write by vnode address (or inode number + FS id) and drivers, which need high performance could add additional logic to do selective barriers. All other FSes (which don't need barriers) and drivers (which don't need this optimization) will work as it is now. It doesn't look like tight coupling, as this stream id could be anything FS want (information of FS structure will not leak though it) and 0 if FS don't want to use this feature. --=20 // Black Lion AKA Lev Serebryakov