title: How to map block numbers to file names from the dmesg output resultant from vm.block_dump=1, if device is ext4?
body: <p><strong>tl;dr:</strong> I want to see/get the filenames that the reported block numbers on dmesg are part of, when <code>vm.block_dump=1</code> example dmesg: <code>bash(13515): READ block 5434824 on xvda3 (32 sectors)</code>  </p>
  
  <p>When eg. <code>sudo sysctl -w vm.block_dump=1</code> or eg. <code>echo '1' | sudo tee /proc/sys/vm/block_dump</code> then "Linux reports all disk read and write operations that take place, and all block dirtyings done to files. [...] The output of block_dump is written to the kernel output, and it can be retrieved using "dmesg". When you use block_dump and your kernel logging level also includes kernel debugging messages, you probably want to turn off klogd, otherwise the output of block_dump will be logged, causing disk activity that is not normally there." (quote from <a href="https://www.kernel.org/doc/Documentation/laptops/laptop-mode.txt" rel="nofollow noreferrer">here</a>)</p>
  
  <p>The "block dirtyings" are not an issue, eg. </p>
  
  <pre><code>[ 3140.559675] systemd-journal(291): dirtied inode 399135 (system.journal) on xvda3
  </code></pre>
  
  <p>I can see its filename like this:</p>
  
  <pre><code>$ echo -e 'open /dev/xvda3\n ncheck 399135' | sudo debugfs -f -
  debugfs 1.44.2 (14-May-2018)
  debugfs: open /dev/xvda3
  debugfs:  ncheck 399135
  Inode   Pathname
  399135  /var/log/journal/12c5e521101c444594b96b53751551a8/system.journal
  </code></pre>
  
  <p>The problem is with "Linux reports all disk read and write operations that take place" (to quote from the above) as they are reported in blocks, eg.</p>
  
  <pre><code>[ 3140.376827] kworker/u24:3(21616): WRITE block 11037768 on xvda3 (8 sectors)
  [ 3140.724725] bash(13515): READ block 5434824 on xvda3 (32 sectors)
  [ 3140.725483] date(13515): READ block 5434896 on xvda3 (160 sectors)
  [ 3140.728946] sed(13519): READ block 5143680 on xvda3 (32 sectors)
  [ 3140.736022] sleep(13522): READ block 5379184 on xvda3 (24 sectors)
  [ 3140.804803] qubes-gui(522): READ block 5179952 on xvda3 (16 sectors)
  [ 3140.806519] Xorg(599): READ block 7420192 on xvda3 (176 sectors)
  [ 3140.810348] InputThread(613): READ block 7418560 on xvda3 (112 sectors)
  [ 3140.815866] at-spi2-registr(812): READ block 5654512 on xvda3 (8 sectors)
  [ 3140.816860] xdg-desktop-por(888): READ block 5795168 on xvda3 (8 sectors)
  [ 3140.818716] gnome-terminal-(865): READ block 5804672 on xvda3 (16 sectors)
  [ 3141.064524] sed(13531): READ block 3446048 on xvda3 (16 sectors)
  [ 3141.130808] systemd(571): READ block 4744136 on xvda3 (184 sectors)
  </code></pre>
  
  <p>The kernel code responsible for showing these kind of messages can be seen here:
  <a href="https://elixir.bootlin.com/linux/v4.18.5/source/block/blk-core.c#L2542" rel="nofollow noreferrer">https://elixir.bootlin.com/linux/v4.18.5/source/block/blk-core.c#L2542</a></p>
  
  <p>None of those blocks yield any inode numbers, using this:</p>
  
  <pre><code>$ echo -e 'open /dev/xvda3\n icheck 11037768' |sudo debugfs -f -
  debugfs 1.44.2 (14-May-2018)
  debugfs: open /dev/xvda3
  debugfs:  icheck 11037768
  Block   Inode number
  11037768    &lt;block not found&gt;
  </code></pre>
  
  <p>Instead of <code>&lt;block not found&gt;</code> above I should get an inode number which I can then use with the previous echo to see the file name.  </p>
  
  <p>What I tried: just in case the block number is sector size(512 bytes) multiple and I know that ext4 block size is 4096 bytes(<code>sudo blockdev --getbsz /dev/xvda</code>), I also tried(using the result of multiplication for): 11037768*2, 11037768*4 and 11037768*8  with the same result: <code>&lt;block not found&gt;</code>  </p>
  
  <p>What am I missing here? Are those blocks pointing to directory entries or something that's not a file name? Even so, shouldn't debugfs still yield an inode number?<br>
  Is there a better way to get to the file name?  </p>
  
  <p><strong>EDIT:</strong> The block number that <code>icheck</code> (inside <code>debugfs</code>) expects are numbers like what debugfs's <code>stat</code> reports under <a href="https://unix.stackexchange.com/a/360398/306023"><code>EXTENTS</code></a>, for example any number in range <code>2172716-2172721</code> seen below as:  </p>
  
  <pre><code>$ sudo debugfs -R "stat /usr/lib/python2.7/site-packages/salt/modules/zonecfg.py" /dev/xvda3
  debugfs 1.44.2 (14-May-2018)
  Inode: 550529   Type: regular    Mode:  0644   Flags: 0x80000
  Generation: 1781055959    Version: 0x00000000:00000001
  User:     0   Group:     0   Project:     0   Size: 22179
  File ACL: 0
  Links: 1   Blockcount: 48
  Fragment:  Address: 0    Number: 0    Size: 0
   ctime: 0x5b6ec29d:1b2e0200 -- Sat Aug 11 13:03:57 2018
   atime: 0x5b33b5a9:00000000 -- Wed Jun 27 18:04:57 2018
   mtime: 0x5b33b5a9:00000000 -- Wed Jun 27 18:04:57 2018
  crtime: 0x5b6ec29d:1af0f900 -- Sat Aug 11 13:03:57 2018
  Size of extra inode fields: 32
  EXTENTS:
  (0-5):2172716-2172721
  </code></pre>
  
  <p>Another way:  </p>
  
  <pre><code>$ filefrag -s -v /usr/lib/python2.7/site-packages/salt/modules/zonecfg.py
  Filesystem type is: ef53
  File size of /usr/lib/python2.7/site-packages/salt/modules/zonecfg.py is 22179 (6 blocks of 4096 bytes)
   ext:     logical_offset:        physical_offset: length:   expected: flags:
     0:        0..       5:    2172716..   2172721:      6:             last,eof
  /usr/lib/python2.7/site-packages/salt/modules/zonecfg.py: 1 extent found
  </code></pre>
  
  <p>Now the question remains: How do those device block numbers (the block numbers reported for xvda3 in dmesg) relate to these physical offsets ?  </p>
  
  <p><strong>EDIT2:</strong> I've just confirmed that these physical offset numbers are the same as block device numbers (just, apparently not the same as the ones reported on dmesg); the following shows me the last block of the above file and I can confirm it being the same as when viewing the file with <code>vim</code>:</p>
  
  <pre><code>$ sudo dd bs=4096 skip=2172721 count=1 if=/dev/xvda3 | hexdump -C
  </code></pre>
  
  <p>I've tested this under a 4.18.5 kernel inside a Qubes OS R4.0 Fedora 28 AppVM. (I can recompile a custom kernel with custom <code>.config</code>/patches if necessary - suggestions welcome)</p>