From owner-freebsd-fs@FreeBSD.ORG  Wed Mar  6 08:23:32 2013
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@FreeBSD.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id A038FAEA;
 Wed,  6 Mar 2013 08:23:32 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242])
 by mx1.freebsd.org (Postfix) with ESMTP id 2CA1F976;
 Wed,  6 Mar 2013 08:23:31 +0000 (UTC)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
 by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r268NNor015235;
 Wed, 6 Mar 2013 00:23:27 -0800 (PST)
 (envelope-from truckman@FreeBSD.org)
Message-Id: <201303060823.r268NNor015235@gw.catspoiler.org>
Date: Wed, 6 Mar 2013 00:23:23 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: Panic in ffs_valloc (Was: Unexpected SU+J inconsistency AGAIN
 -- please, don't shift topic to ZFS!)
To: lev@FreeBSD.org
In-Reply-To: <958644234.20130306105205@serebryakov.spb.ru>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=iso-8859-5
Content-Transfer-Encoding: 8BIT
Cc: mckusick@mckusick.com, freebsd-fs@FreeBSD.org
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2013 08:23:32 -0000

On  6 Mar, Lev Serebryakov wrote:
> Hello, Don.
> You wrote 6 марта 2013 г., 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
>  :)

Performance when deleting multi-gigabyte, low-value files would kind of
suck if we did that ...