On Mon, Dec 18, 2017 at 04:41:50PM +0100, Carlos Maiolino wrote:
> On Mon, Dec 18, 2017 at 07:16:33PM +0800, Vaughan wrote:
> > Hi All,
> >
> >
> > I encounter the following output from time to time. Since xfs is built on
> > our own virtual disk, it's more likely that our vdisk is buggy.
> > Can anyone tell me how to figure out the on-disk location given the block
> > number? Does it follow the following formula?
> > On-disk location = <block number from metadata I/O error> * <bsize of data
> > section of xfs_info>
> > However, the result from the above formula suggests the metadata is out of
> > range of my disk, confused...
>
> No, your formula is not correct. XFS filesystem blocks are not exactly
> sequentially arranged as your formula suggests. It depends on the number of
> blocks in each Allocation Group, and the Log2 number used to make calculations
> regarding disk addresses.
>
> Easier answer: Use xfs_db to convert it:
>
> xfs_db> fsblock 0x1e8ffa08
> xfs_db> daddr
> current daddr is 2639245888
One little, important detail is wrong here: metadata block numbers
are reported as daddrs, not fsblocks. daddrs are units of basic
blocks and are a linear offset from the start of the device. Basic
blocks are always 512 bytes. i.e. neither the OP or the above is
correct. :/
XFS (md_d27): metadata I/O error: block 0x1e8ffa08 ("xfs_trans_read_buf_map") error 117 numblks 8
Hence this is an error from a read at daddr 0x1e8ffa08 for 8 basic
blocks (4096 bytes). Looks like something has overwritten the AGF
with crap...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
