From owner-svn-src-head@FreeBSD.ORG  Thu Nov 14 09:47:18 2013
Return-Path: <owner-svn-src-head@FreeBSD.ORG>
Delivered-To: svn-src-head@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 ESMTPS id 7BC318CE;
 Thu, 14 Nov 2013 09:47:18 +0000 (UTC)
Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69])
 by mx1.freebsd.org (Postfix) with ESMTP id 59E942B1E;
 Thu, 14 Nov 2013 09:47:18 +0000 (UTC)
Received: from fledge.watson.org (fledge.watson.org [198.74.231.63])
 by cyrus.watson.org (Postfix) with ESMTPS id D3E1746B52;
 Thu, 14 Nov 2013 04:47:16 -0500 (EST)
Date: Thu, 14 Nov 2013 09:47:16 +0000 (GMT)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Colin Percival <cperciva@FreeBSD.org>
Subject: Re: svn commit: r258124 - head/usr.sbin/portsnap/portsnap
In-Reply-To: <201311140922.rAE9MW39043456@svn.freebsd.org>
Message-ID: <alpine.BSF.2.00.1311140945560.10113@fledge.watson.org>
References: <201311140922.rAE9MW39043456@svn.freebsd.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org,
 src-committers@freebsd.org
X-BeenThere: svn-src-head@freebsd.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: SVN commit messages for the src tree for head/-current
 <svn-src-head.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-head>,
 <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>
List-Post: <mailto:svn-src-head@freebsd.org>
List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>,
 <mailto:svn-src-head-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2013 09:47:18 -0000

On Thu, 14 Nov 2013, Colin Percival wrote:

> Log:
>  When verifying that files we need are present, also check that they don't
>  have zero length.  Filesystem corruption will tend to truncate files, and
>  since these are short that's likely to result in them becoming empty.
>
>  Suggested by:	Richard Clayton
>  Convinced by:	rwatson
>  MFC after:	3 weeks

I think I'd probably express this slightly differently: the filesystem isn't 
corrupted, it just doesn't contain the data you expect.  As filesystems don't 
guarantee data is there until fsync() has returned, it is actually meeting all 
its promises -- e.g., vs corrupted inode contents due to a filesystem bug.

Robert