lkml.org 
[lkml]   [2009]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: block_dump - full path ?
On Sat, Sep 05, 2009 at 11:44:35PM +0200, devzero@web.de wrote:
> Hi,
>
> i came across the nice debugging feature sysctl vm.block_dump=1 which leaves information on read/write in dmesg for every process.
>
> Sep 5 20:11:15 neoware kernel: kjournald(423): WRITE block 155542512 on sda2
> Sep 5 20:11:15 neoware kernel: kjournald(423): WRITE block 155542520 on sda2
> Sep 5 20:11:15 neoware kernel: kjournald(423): WRITE block 155542528 on sda2
> Sep 5 20:11:19 neoware kernel: pdflush(14): WRITE block 144498288 on sda2
> Sep 5 20:11:19 neoware kernel: pdflush(14): WRITE block 144916496 on sda2
> Sep 5 20:11:19 neoware kernel: pdflush(14): WRITE block 144917376 on sda2
> Sep 5 20:11:19 neoware kernel: pdflush(14): WRITE block 144704600 on sda2
>
> is it possible to log the full path of the process ?

What do you mean by "the full path of the process"? Do you mean the
full path of the process' executable? (In this case kjournald and
pdflush are kernel threads so there is no executable, and thus there
is no "full path". unless you mean pathname to the kernel, i.e., /vmlinux.)

Or did you mean the full path name of the file associated with the
block number? In this case, kjournald is writing to the file system
journal, which has no pathname. pdflush is writing dirty pages from
the page cache, which could be mapped to file names, but it would take
up a huge amount of space in the log -- but to what effect?

What exactly are you trying to do? There might be a more efficient
way of gathering whatever data you are trying to get for your experiment.

- Ted


\
 
 \ /
  Last update: 2009-09-06 17:55    [W:0.050 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site