From owner-freebsd-stable@FreeBSD.ORG Mon Jun 23 08:55:29 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 106741065672; Mon, 23 Jun 2008 08:55:29 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id E156B8FC2A; Mon, 23 Jun 2008 08:55:27 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 23 Jun 2008 09:55:26 +0100 (BST) Date: Mon, 23 Jun 2008 09:55:25 +0100 From: David Malone To: Jeremy Chadwick Message-ID: <20080623085525.GA95600@walton.maths.tcd.ie> References: <485BA3D2.3090108@bulinfo.net> <20080620132833.GB83165@rink.nu> <20080620140623.GC83165@rink.nu> <485F4930.601@bulinfo.net> <20080623071928.GA13020@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080623071928.GA13020@eos.sc1.parodius.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-stable@FreeBSD.org, Ivan Voras Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2008 08:55:29 -0000 On Mon, Jun 23, 2008 at 12:19:28AM -0700, Jeremy Chadwick wrote: > I've used SpamAssassin for a few years now, and I've never seen this > happen (including during migration from RELENG_6 to RELENG_7, and > between SpamAssassin versions (from 3.0 to 3.2.x). I cannot even begin > to imagine how that file reached such a size, which is why I believe the > issue may be filesystem corruption. I've seen spamassassin creating large sparse file regurally and do other strang things like get the database into a state where it spins if it trys to clean it out. That's even starting with a clean database. > There isn't any way to solve this problem. The file, as far as dump is > concerned, is indeed 3TB. Dump does understand sparse files, but doesn't store them in the most efficient way possible. Dumping a filesystem with a 1TB file seems to use about 2GB. David. # truncate -s 1T /var/tmp/bigfile # dump 0Lf - /var | wc -c DUMP: Date of this level 0 dump: Mon Jun 23 09:50:50 2008 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/ad4s3d (/var) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 2212849 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 2212776 tape blocks DUMP: finished in 59 seconds, throughput 37504 KBytes/sec DUMP: DUMP IS DONE 2265876480