blktrace and xfs_db block offset mismatch

[Sushma R]

Please ignore my last comment. It doesn't make sense since file system is
mounted on a disk partition.

>>Also, I'm not familiar enough with blktrace output off the top of my
>>head so perhaps not an issue, but it's not clear to me whether the
>>output above could have been converted/adjusted to a raw address based
>>on a device partition.

Yes, it appears that blktrace adds device partition offset.

Thanks!!


On Sat, Sep 27, 2014 at 8:40 AM, Sushma R <gsushma at gmail.com> wrote:

> Thanks Brian.
>
> I'm trying to understand how the internal XFS structures affect this
> mapping (
> http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf)
>
> xfs_bmap on the file matches that reported by extents in the file inode
> using xfs_db.
>
> Other conversions under xfs_db
> xfs_db> convert fsb 2621481 agno
> 0x0 (0)
> xfs_db> convert fsb 2621481 agbno
> 0x280029 (2621481)
> xfs_db> convert fsb 2621481 daddr
> 0x1400148 (20971848)
>
> I tried dd command with directio option and still blktrace reports the
> same raw block number as earlier.
> 8,17   3        1     0.000000000  6999  D   R 20973896 + 1 [dd]
>
> I'm using xfs_db with the partition i.e. "xfs_db -r /dev/sdb1"
> However, if I use it on the whole disk "xfs_db -r /dev/sdb", it gives the
> following error
> xfs_db: cannot init perag data (117)
>
> Does this suggest something?
>
> Thanks,
> Sushma
>
> On Sat, Sep 27, 2014 at 7:38 AM, Brian Foster <bfoster at redhat.com> wrote:
>
>> On Sat, Sep 27, 2014 at 12:32:21AM -0700, Sushma R wrote:
>> > Hi,
>> >
>> > I ran blktrace while reading a file on XFS partition and here's it's
>> output.
>> >
>> > 8,17   3        1    22.065944956  5489  D   R 20973896 + 8 [cat]
>> >
>> > Using xfs_db, I dumped the inode for the same file and it shows the
>> > following as its data extents.
>> >
>> > u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,2621481,1,0]
>> >
>> > I understand that blktrace reports in 512-byte sectors while xfs_db in
>> > filesystem block size (which is the default 4KB on my setup).
>> > Converting blktrace offset to fs block = 2621737 which is close to the
>> data
>> > extent startblock (2621481), but still off by 256 fs blocks.
>> >
>> > Could someone please help understand the reason for this mismatch?
>> >
>>
>> I believe you are comparing a raw read of a device to an internal XFS
>> fsb, the latter of which is encoded to account for the internal
>> structure of XFS (e.g., allocation groups). You might want to take a
>> look at xfs_bmap on the file to see the actual disk blocks.
>>
>> The fsb to daddr conversion depends on the geometry of the fs, but you
>> can get the various values with xfs_db as well. E.g.:
>>
>> convert fsb 2621481 agno        # ag number
>> convert fsb 2621481 agbno       # relative ag block nr
>> convert fsb 2621481 daddr       # disk address
>>
>> Also, I'm not familiar enough with blktrace output off the top of my
>> head so perhaps not an issue, but it's not clear to me whether the
>> output above could have been converted/adjusted to a raw address based
>> on a device partition.
>>
>> You might also want to verify you're looking at the actual file read vs.
>> a directory/inode lookup or block mapping lookup or something else. I
>> see you're running cat, a direct I/O read via dd might ensure you aren't
>> just pulling file data from cache.
>>
>> Brian
>>
>> > Thanks,
>> > Sushma
>>
>> > _______________________________________________
>> > xfs mailing list
>> > xfs at oss.sgi.com
>> > http://oss.sgi.com/mailman/listinfo/xfs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20140927/0e36539f/attachment.html>