From: Dave Chinner <david@fromorbit.com>
To: Andy Isaacson <adi@hexapodia.org>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: XFS stat/statvfs problems with 2.6.38-rc2-00175-g6fb1b30
Date: Thu, 3 Feb 2011 09:18:58 +1100 [thread overview]
Message-ID: <20110202221858.GS11040@dastard> (raw)
In-Reply-To: <20110202023644.GA25214@hexapodia.org>
On Tue, Feb 01, 2011 at 06:36:44PM -0800, Andy Isaacson wrote:
> Since updating past 2.6.37, I'm seeing du(1) sometimes report files
> taking up 8GB even though ls(1) reports the correct size (hundreds of
> bytes). At the same time, df reports that the filesystem is 95% or 100%
> full (although I can still write to the filesystem). Repeated du calls
> show persistent results (once st_blocks is wrong, it stays wrong).
> Rebooting clears the problem for a few hours, then it seems to come
> back, although the exact files affected seems to change. xfs_check
> doesn't find any errors, and rebooting into 2.6.37 clears up the problem
> entirely.
>
> There's nothing in dmesg indicating a problem:
>
> Jan 27 08:04:37 pyron kernel: [ 0.000000] Linux version 2.6.38-rc2-00175-g6fb1b30 (adi@pyron) (gcc version 4.4.5 (Debian 4.4.5-10) ) #75 SMP Thu Jan 27 00:39:11 PST 2011
> Jan 27 08:04:37 pyron kernel: [ 8.420170] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
> Jan 27 08:04:37 pyron kernel: [ 8.434527] XFS mounting filesystem dm-8
> Jan 27 08:04:37 pyron kernel: [ 8.676644] Starting XFS recovery on filesystem: dm-8 (logdev: internal)
> Jan 27 08:04:37 pyron kernel: [ 8.734279] Ending XFS recovery on filesystem: dm-8 (logdev: internal)
> Jan 27 08:04:37 pyron kernel: [ 8.762724] XFS mounting filesystem dm-9
> Jan 27 08:04:37 pyron kernel: [ 8.957986] Ending clean XFS mount for filesystem: dm-9
> Jan 27 08:04:37 pyron kernel: [ 8.985909] XFS mounting filesystem dm-10
> Jan 27 08:04:37 pyron kernel: [ 9.098404] Starting XFS recovery on filesystem: dm-10 (logdev: internal)
> Jan 27 08:04:37 pyron kernel: [ 9.205018] Ending XFS recovery on filesystem: dm-10 (logdev: internal)
>
>
> /d1 is a 200GB XFS on DM on AHCI SATA on a Core i7 desktop board.
> The erroneous statvfs reports are visible in this munin graph:
> http://web.hexapodia.org/~adi/tmp/20110201-df-pyron.png
> (the filesystem is actually 72% full currently, and should be linearly
> filling as is visible around Jan 26.)
It'll be the excessive specualtive preallocation bug introduced in
.38-rc1 which is fixed in .38-rc3.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Andy Isaacson <adi@hexapodia.org>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: XFS stat/statvfs problems with 2.6.38-rc2-00175-g6fb1b30
Date: Thu, 3 Feb 2011 09:18:58 +1100 [thread overview]
Message-ID: <20110202221858.GS11040@dastard> (raw)
In-Reply-To: <20110202023644.GA25214@hexapodia.org>
On Tue, Feb 01, 2011 at 06:36:44PM -0800, Andy Isaacson wrote:
> Since updating past 2.6.37, I'm seeing du(1) sometimes report files
> taking up 8GB even though ls(1) reports the correct size (hundreds of
> bytes). At the same time, df reports that the filesystem is 95% or 100%
> full (although I can still write to the filesystem). Repeated du calls
> show persistent results (once st_blocks is wrong, it stays wrong).
> Rebooting clears the problem for a few hours, then it seems to come
> back, although the exact files affected seems to change. xfs_check
> doesn't find any errors, and rebooting into 2.6.37 clears up the problem
> entirely.
>
> There's nothing in dmesg indicating a problem:
>
> Jan 27 08:04:37 pyron kernel: [ 0.000000] Linux version 2.6.38-rc2-00175-g6fb1b30 (adi@pyron) (gcc version 4.4.5 (Debian 4.4.5-10) ) #75 SMP Thu Jan 27 00:39:11 PST 2011
> Jan 27 08:04:37 pyron kernel: [ 8.420170] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
> Jan 27 08:04:37 pyron kernel: [ 8.434527] XFS mounting filesystem dm-8
> Jan 27 08:04:37 pyron kernel: [ 8.676644] Starting XFS recovery on filesystem: dm-8 (logdev: internal)
> Jan 27 08:04:37 pyron kernel: [ 8.734279] Ending XFS recovery on filesystem: dm-8 (logdev: internal)
> Jan 27 08:04:37 pyron kernel: [ 8.762724] XFS mounting filesystem dm-9
> Jan 27 08:04:37 pyron kernel: [ 8.957986] Ending clean XFS mount for filesystem: dm-9
> Jan 27 08:04:37 pyron kernel: [ 8.985909] XFS mounting filesystem dm-10
> Jan 27 08:04:37 pyron kernel: [ 9.098404] Starting XFS recovery on filesystem: dm-10 (logdev: internal)
> Jan 27 08:04:37 pyron kernel: [ 9.205018] Ending XFS recovery on filesystem: dm-10 (logdev: internal)
>
>
> /d1 is a 200GB XFS on DM on AHCI SATA on a Core i7 desktop board.
> The erroneous statvfs reports are visible in this munin graph:
> http://web.hexapodia.org/~adi/tmp/20110201-df-pyron.png
> (the filesystem is actually 72% full currently, and should be linearly
> filling as is visible around Jan 26.)
It'll be the excessive specualtive preallocation bug introduced in
.38-rc1 which is fixed in .38-rc3.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2011-02-02 22:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-02 2:36 XFS stat/statvfs problems with 2.6.38-rc2-00175-g6fb1b30 Andy Isaacson
2011-02-02 2:36 ` Andy Isaacson
2011-02-02 22:18 ` Dave Chinner [this message]
2011-02-02 22:18 ` Dave Chinner
2011-02-03 1:18 ` Andy Isaacson
2011-02-03 1:18 ` Andy Isaacson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110202221858.GS11040@dastard \
--to=david@fromorbit.com \
--cc=adi@hexapodia.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.