Re: XFS, empty files after a crash

[Dave Chinner <david@fromorbit.com>]

On Tue, Feb 21, 2012 at 01:01:43PM +0100, kfx wrote:
> Hi,
> 
> After a crash, a lot of files on a xfs file system report an empty
> size with "ls -a" but not with "du".
> xfs_check and xfs_repair don't report any problem to repair
> (although an internal log is used) :(
> So if I understand correctly, those empty files actually use space
> on the disk but are incorrectly reported as empty by the system.
> Is there a way to copy back the used blocks to recover the files ?
> 
> Example for a previously not empty file:
> # ls -l myfile
> -rw-r--r-- 1 me me 0 2012-01-24 15:29 myfile
> 
> # du  myfile
> 27460    myfile
> 
> # du --apparent-size myfile
> 0    myfile
> 
> # xfs_bmap myfile
> myfile: no extents

That doesn't seem right:

$ ls -l foobar
-rw------- 1 root root 0 Feb 27 11:54 foobar
$ du foobar 
1024    foobar
$ du --apparent-size foobar 
0       foobar
$ xfs_bmap foobar
foobar:
	0: [0..2047]: 255169872..255171919

So xfs_bmap can and does report extents beyond EOF.

du uses the fstat(2) syscall to get the block count from the inode,
so it's seeing an inode with a block count but no extents. Can you
dump the inode via xfs_db like so:

$ ls -i foobar
604424233 foobar
$ sudo xfs_db -r -c "inode 604424233" -c p /dev/md0
core.magic = 0x494e
core.mode = 0100600
core.version = 2
.....

And post the output?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs