On Mon, Feb 27, 2012 at 09:43:42AM +0100, kadafax@xxxxxxxxx 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@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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
