XFS, empty files after a crash

[Dave Chinner]

On Mon, Feb 27, 2012 at 09:43:42AM +0100, kadafax at gmail.com wrote:
> Le 27/02/12 02:04, Dave Chinner a écrit :
> >On Tue, Feb 21, 2012 at 01:01:43PM +0100, kfx wrote:
> >># 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:
.....
> [root at server 1_out]# xfs_db -r -c "inode 114748" -c p /dev/sdc1
> core.magic = 0x494e
> core.mode = 0100644
> core.version = 2
> core.format = 2 (extents)
.....
> core.size = 0
> core.nblocks = 6460
> core.extsize = 0
> core.nextents = 1
.....
> core.prealloc = 0
....
> core.extsz = 0
> core.extszinherit = 0
....
> u.bmx[0] = [startoff,startblock,blockcount,extentflag]
> 0:[0,1881705728,6460,0]

Ok, so there's an extent there, but xfs_bmap is not showing it
because it isn't a preallocation but rather a normal extent. What
this indicates is that the inode size was not updated on disk after
the data write had occurred.

Given you are running 2.6.38 (the unbuntu kernel), this is likely
caused by a known bug introduced in 2.6.37 by VFS changes outside
XFS to prevent sync livelocks. That has been fixed in current 3.0.x
stable kernels and more recent 3.2+ kernels.  I'd suggest upgrading
your kernel.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com