Re: Map a disk LBA to filename?

[Michal Soltys <nozo@drutsystem.com>]

Carsten Aulbert wrote:
> Michal Soltys wrote:
>> 
>> Wouldn't something like (under xfs_db) :
>> 
>> getblock -b #block -n
>> ncheck -i #inode
>> 
>> where required #inode is reported by getblock
>> 
>> do the thing ?
>> 
> 
> Sounds nice, but my (ancient? 2.8.11) version of xfs_db does not know
> getblock (only blockget) since that also matches the command line and
> the usage looks about to be right, I'm currently trying that one, e.g.
> 

Sorry, I meant blockget.

> smartctl reports a bad LBA at 36922326. fdisk tells me the partition
> starts at 31069773, hence the block under question is 5852553.
> 
> xfs_info tells be a bsize of 4096 which I take as the block size, thus
> the xfs block to look at should be 731569, right?
> 
> xfs_db> blockget -b 731569 -n
> setting block 0/731569 to free1
> setting block 0/731569 to free2
> xfs_db>
> 
> hmm, no inode number. Does that mean this block is not used by any file
> currently - which might be perfectly fine since this partition is only
> 31% full.
> 
> Everything right so far?
> 

Yes, calculations look fine. I'm not sure what exactly is the difference 
between free1 and free2 - someone more knowledgable would have to 
comment (and overally comment about this method).

In my case when I check block allocated by some file, I get results such as:

xfs_db> blockget -b 4584722 -n
setting block 0/4584722 to data
setting inode to 36231069 for block 0/4584722
inode 36231069 block 4584722 at offset 810
sb_fdblocks 1330583, aggregate AGF count 7983498
xfs_db> ncheck -i 36231069
    36231069 stuff/data/arst.dat

and further:

xfs_db> inode 36231069
xfs_db> bmap
data offset 0 startblock 4583912 (0/4583912) count 832 flag 0

Here the file lies in the first extent, taking 832*4096 blocks.