From owner-freebsd-fs@FreeBSD.ORG  Fri Aug 28 18:51:28 2009
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 98DF5106564A
	for <freebsd-fs@freebsd.org>; Fri, 28 Aug 2009 18:51:28 +0000 (UTC)
	(envelope-from aragon@phat.za.net)
Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81])
	by mx1.freebsd.org (Postfix) with ESMTP id 34BF78FC0A
	for <freebsd-fs@freebsd.org>; Fri, 28 Aug 2009 18:51:28 +0000 (UTC)
Received: from fuzz.geek.sh (unknown [196.209.244.32])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.geek.sh (Postfix) with ESMTPSA id 38B713BBC8
	for <freebsd-fs@freebsd.org>; Fri, 28 Aug 2009 20:36:11 +0200 (SAST)
Message-ID: <4A9822FC.2030606@phat.za.net>
Date: Fri, 28 Aug 2009 20:33:32 +0200
From: Aragon Gouveia <aragon@phat.za.net>
User-Agent: Thunderbird 2.0.0.22 (X11/20090628)
MIME-Version: 1.0
To: freebsd-fs@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: some of my files have an incorrect block count
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/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: Fri, 28 Aug 2009 18:51:28 -0000

Hi,

I'm copying data across to a larger file system and in so doing, I've 
noticed that some of the files in my old file system have an incorrect 
block count.  After copying all data, df(1) reports that the new file 
system has more data on it than the old one.  I've narrowed most of the 
difference to one file in particular:

%ls -l /data/qemu/winxp.qem /mnt/data/qemu/winxp.qem
-rw-r--r--  1 aragon  staff  10737418240 Mar 29 21:57 /data/qemu/winxp.qem
-rw-r--r--  1 aragon  staff  10737418240 Mar 29 21:57 
/mnt/data/qemu/winxp.qem

%du -k /data/qemu/winxp.qem /mnt/data/qemu/winxp.qem
10490896	/data/qemu/winxp.qem
2001728	/mnt/data/qemu/winxp.qem

%du -Ak /data/qemu/winxp.qem /mnt/data/qemu/winxp.qem
10485760	/data/qemu/winxp.qem
10485760	/mnt/data/qemu/winxp.qem

%stat -f '%N: %z %b' /data/qemu/winxp.qem /mnt/data/qemu/winxp.qem
/data/qemu/winxp.qem: 10737418240 20981792
/mnt/data/qemu/winxp.qem: 10737418240 4003456

In the above the new file system is /data, the old /mnt/data.

Running fsck(8) on the old file system doesn't show any errors and makes 
no difference.

If dd(1) reads both files in, it counts the correct size, and running 
md5(1) on both copies of the files produces the same hash, so at least 
all the data is presumably present.

Surely fsck(8) should detect this?

Is this inconsistency cause for concern?


Thanks,
Aragon