Re: blktrace and xfs_db block offset mismatch

From: Brian Foster <bfoster@redhat.com>
To: Sushma R <gsushma@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: blktrace and xfs_db block offset mismatch
Date: Sat, 27 Sep 2014 10:38:59 -0400	[thread overview]
Message-ID: <20140927143859.GA60739@bfoster.bfoster> (raw)
In-Reply-To: <CAOj3taPoXpVktWJxmYKLZrvfe7T1qYArLsoQ39gsMdj_T1hNYg@mail.gmail.com>

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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs