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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
