* blktrace and xfs_db block offset mismatch @ 2014-09-27 7:32 Sushma R 2014-09-27 14:38 ` Brian Foster 0 siblings, 1 reply; 4+ messages in thread From: Sushma R @ 2014-09-27 7:32 UTC (permalink / raw) To: xfs [-- Attachment #1.1: Type: text/plain, Size: 678 bytes --] 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? Thanks, Sushma [-- Attachment #1.2: Type: text/html, Size: 915 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: blktrace and xfs_db block offset mismatch 2014-09-27 7:32 blktrace and xfs_db block offset mismatch Sushma R @ 2014-09-27 14:38 ` Brian Foster 2014-09-27 15:40 ` Sushma R 0 siblings, 1 reply; 4+ messages in thread From: Brian Foster @ 2014-09-27 14:38 UTC (permalink / raw) To: Sushma R; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: blktrace and xfs_db block offset mismatch 2014-09-27 14:38 ` Brian Foster @ 2014-09-27 15:40 ` Sushma R 2014-09-27 16:53 ` Sushma R 0 siblings, 1 reply; 4+ messages in thread From: Sushma R @ 2014-09-27 15:40 UTC (permalink / raw) To: Brian Foster; +Cc: xfs [-- Attachment #1.1: Type: text/plain, Size: 2944 bytes --] 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@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@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > > [-- Attachment #1.2: Type: text/html, Size: 4810 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: blktrace and xfs_db block offset mismatch 2014-09-27 15:40 ` Sushma R @ 2014-09-27 16:53 ` Sushma R 0 siblings, 0 replies; 4+ messages in thread From: Sushma R @ 2014-09-27 16:53 UTC (permalink / raw) To: Brian Foster; +Cc: xfs [-- Attachment #1.1: Type: text/plain, Size: 3543 bytes --] 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@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@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@oss.sgi.com >> > http://oss.sgi.com/mailman/listinfo/xfs >> >> > [-- Attachment #1.2: Type: text/html, Size: 6584 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-09-27 17:24 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-27 7:32 blktrace and xfs_db block offset mismatch Sushma R 2014-09-27 14:38 ` Brian Foster 2014-09-27 15:40 ` Sushma R 2014-09-27 16:53 ` Sushma R
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox