Date: Thu, 23 Jun 2011 17:24:12 +0200 From: Peter Holm <peter@holm.cc> To: Hans Ottevanger <hans@beastielabs.net> Cc: Kirk McKusick <mckusick@mckusick.com>, freebsd-fs@freebsd.org, Jeff Roberson <jroberson@chesapeake.net> Subject: Re: SU+J: negative used diskspace (for a while) Message-ID: <20110623152412.GA48574@x2.osted.lan> In-Reply-To: <20110623144538.GA20990@testsoekris.hotsoft.nl> References: <20110617153415.GA92803@testsoekris.hotsoft.nl> <201106171842.p5HIgQjn018296@chez.mckusick.com> <20110621084645.GA68018@server.vk2pj.dyndns.org> <20110623144538.GA20990@testsoekris.hotsoft.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 23, 2011 at 04:45:38PM +0200, Hans Ottevanger wrote: > On Tue, Jun 21, 2011 at 06:46:45PM +1000, Peter Jeremy wrote: > > On 2011-Jun-17 11:42:26 -0700, Kirk McKusick <mckusick@mckusick.com> wrote: > > >> Date: Fri, 17 Jun 2011 17:34:15 +0200 > > >> From: Hans Ottevanger <hans@beastielabs.net> > > >> So it takes more than a minute before the disk space is back to "normal" > > >> values. > > > > >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. > > > > Negative values may also impact NFS clients - though just limiting the > > reported used space to 0 should avoid them getting too upset. > > > > It appears that negative values occur only when the filesystem is almost > empty (like in my tests). Otherwise the values are just way too low for > a while. > > > That said, whilst I haven't seen negative used values, ZFS and > > Solaris UFS also take an extended period before 'df' reports > > correct values (several minutes for Solaris UFS). In the case > > of ZFS, even 'du' can report incorrect information for a while. > > > > If I remember well, in "the old days", when Soft Updates was fairly new, > it also had such issues in the first release, but it was repaired soon > afterwards. > > Of course it is a real advantage to see the results immediately when you > are cleaning out filesystems, especially when you are in a hurry. > > I just verified that the current issue was quite recently introduced with > commit r222958. Before that 'df' reported changes promptly and correctly, > even with Journaling enabled. > > As an answer to my original message to -current@ Peter Holm has assured me > (http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025318.html) > that this is a known issue that is on Jeff's TODO list. > Ah, well my exact wording was "This is a known issue and I believe that it is on Jeff's to-do list". So I'm afraid I can only assure you that the problem is known :) - Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110623152412.GA48574>