xfs
[Top] [All Lists]

Re: XFS, empty files after a crash

To: kfx <kadafax@xxxxxxxxx>
Subject: Re: XFS, empty files after a crash
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 27 Feb 2012 12:04:02 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4F4387A7.2070009@xxxxxxxxx>
References: <4F4387A7.2070009@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>