On 8/25/15 4:08 AM, zhengbin.08747@xxxxxxx wrote:
> My OS is redhat7.1, the version of Linux kernel is “Linux version 3.10.0-229.el7.x86_64”
>
> Sometime xfs give a message like this
>
> Aug 11 15:51:05 localhost kernel: XFS (dm-4): metadata I/O error: block 0x7d9a010 ("xfs_trans_read_buf_map") error 117 numblks 16
> Aug 11 15:51:05 localhost kernel: XFS (dm-4): xfs_imap_to_bp: xfs_trans_read_buf() returned error 117.
> Aug 11 15:31:08 localhost kernel: XFS (dm-4): Metadata corruption detected at xfs_inode_buf_verify+0x75/0xd0 [xfs], block 0x7d9a010
> Aug 11 15:31:08 localhost kernel: XFS (dm-4): Unmount and run xfs_repair
Did you try running xfs_repair (or possibly better for the first run, do xfs_repair -n, to do a check-only run?)
> Aug 11 15:31:08 localhost kernel: XFS (dm-4): First 64 bytes of corrupted metadata buffer:
> Aug 11 15:31:08 localhost kernel: ffff88089144a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> Aug 11 15:31:08 localhost kernel: ffff88089144a010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> Aug 11 15:31:08 localhost kernel: ffff88089144a020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> Aug 11 15:31:08 localhost kernel: ffff88089144a030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
So it seems to have read a completely zeroed-out block.
Isn't there a stack trace after this part of the message?
Hm I guess not; if you can hit it again, try
# sysctl -w fs.xfs.error_level=11
to turn up the error reporting level.
Any chance that this is a thinly provisioned device? Or what type of dm device is it?
> So is this a bug of xfs? or is the device’s error(the device actually did not save the data, but give xfs success message)?
Hard to say at this point.
-Eric
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
