From owner-freebsd-fs@FreeBSD.ORG Fri Jun 17 18:43:42 2011 Return-Path: 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 39804106566C for ; Fri, 17 Jun 2011 18:43:42 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (unknown [IPv6:2001:470:8761:2:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id E08A28FC0A for ; Fri, 17 Jun 2011 18:43:37 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p5HIgQjn018296; Fri, 17 Jun 2011 11:42:30 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201106171842.p5HIgQjn018296@chez.mckusick.com> To: Hans Ottevanger In-reply-to: <20110617153415.GA92803@testsoekris.hotsoft.nl> Date: Fri, 17 Jun 2011 11:42:26 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org, Jeff Roberson Subject: Re: SU+J: negative used diskspace (for a while) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:43:42 -0000 > Date: Fri, 17 Jun 2011 17:34:15 +0200 > From: Hans Ottevanger > To: freebsd-current@freebsd.org > Subject: SU+J: negative used diskspace (for a while) > > Hi, > > I found a possible issue with SU+J on recent versions of -CURRENT. > > After deleting a large file hierarchy (copy of /usr/src, ~1.5 Gbyte), > df reports a negative number of blocks "Used" for a while. > > I am using a GENERIC kernel (r223184) on an amd64 platform. The hardware > is relatively simple: Intel DP965LT mainboard with a Q6600 CPU, 8 Gbyte > RAM and two Samsung 501LJ 500 Gbyte SATA disks. > > The issue can be demonstrated by copying /usr/src to the current directory > (cp -R /usr/src .) and running the following script to delete the copy > and print the free space at 10 second intervals: > > #!/bin/sh > > df . > > time rm -rf src > > echo 'src is gone ...' > > while true > do > df . | tail -1 > sleep 10 > done > > This yields the following output: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ada0s1g 416144900 1612066 381241242 0% /home > 51.21 real 1.00 user 17.38 sys > src is gone ... > /dev/ada0s1g 416144900 -164692 383018000 -0% /home > /dev/ada0s1g 416144900 -165082 383018390 -0% /home > /dev/ada0s1g 416144900 -246852 383100160 -0% /home > /dev/ada0s1g 416144900 -246852 383100160 -0% /home > /dev/ada0s1g 416144900 -246852 383100160 -0% /home > /dev/ada0s1g 416144900 -64146 382917454 -0% /home > /dev/ada0s1g 416144900 -64146 382917454 -0% /home > /dev/ada0s1g 416144900 -64146 382917454 -0% /home > /dev/ada0s1g 416144900 32910 382820398 0% /home > /dev/ada0s1g 416144900 32910 382820398 0% /home > > So it takes more than a minute before the disk space is back to "normal" > values. > > After disabling journaling (tunefs -j disable) I get the following output: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ada0s1g 416144900 1579284 381274024 0% /home > 35.40 real 0.96 user 13.32 sys > src is gone ... > /dev/ada0s1g 416144900 128 382853180 0% /home > /dev/ada0s1g 416144900 128 382853180 0% /home > /dev/ada0s1g 416144900 128 382853180 0% /home > /dev/ada0s1g 416144900 128 382853180 0% /home > > which is as it should be. > > The problem also does not occur with journaling enabled when I revert > to r222723. > > Is anybody else seeing these weird phenomena? > Could this be related to the recent changes to UFS? > > Kind regards, > > Hans Ottevanger We used to account for deleted blocks at the instant that they were removed. This accounting was rather complex, so as part of doing SU+J, Jeff simplified it. Under the simplification, the removal is not accounted for until part way through the removal process. The result is that you now get these false negative block counts until the blocks have been partially reclaimed. If this behavior causes enough trouble, Jeff might be convinced that the more accurate block accounting is necessary. Kirk McKusick