archive mirror
 help / color / mirror / Atom feed
From: "熊毓华 via lttng-dev" <>
To: "Genevieve Bastien" <>,
	 "" <>
Cc: "" <>,
	 "" <>,
	 "" <>
Subject: Re: [lttng-dev] questions about mapping from file names to corresponding inode
Date: Tue, 12 May 2020 00:18:51 +0800 (GMT+08:00)	[thread overview]
Message-ID: <> (raw)
Message-ID: <20200511161851.2XSI9gCp3TZ1erUq95gp0JshRszGx9QEPs7WwRST7MA@z> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 3308 bytes --]

Hi Geneviève,

Sorry for bothering you again for this problem.

Here is a brief description of the problem we encountered.
We are going to build a Linux data collector based on lttng. In some scenarios, the Linux server will perform a lot of file creation and deletion operations. At this time, a hashmap that stores file nodes in our collecotor will explode as the number of files increases. Therefore, we need to remove those file nodes that have been deleted in the hashmap in time.
At first, we wanted to know whether a file node still exists by finding the correspondence between file name and inode in lttng  trace data.  If the file has been deleted, its corresponding inode number cannot be obtained through its filename.Then, we want to find the mapping from file names to corresponding inode in lttng trace data.So I sent you this email.

But it seems that this correspondence cannot be obtained from the lttng trace data, so we are now taking another method to know whether a file node has been deleted through the trace data of unlink or unlinkat sys.

Do you have any suggestions on this question?



发件人:"Genevieve Bastien" <>
发送时间:2020-05-11 21:53:43 (星期一)
收件人: "熊毓华" <>
主题: Re: [lttng-dev] questions about mapping from file names to corresponding inode

Hi Yuhua,

What are you trying to achieve exactly with this data? I've been looking around this area recently.

We wanted to be able to match requests to disk (block_rq/bio) with the writes to file from the various threads. I looked at the block_dirty_buffer event, as well as writeback_dirty_page. For the block, the dirty buffers are by partition, while the requests are for the device. There is an event (block_bio_remap) that should map the sector from the partition to the sector from the device, but I found no later block requests that included those sectors. I've thus put this investigation on pause for now.

That may not be related to what you're doing, but just in case, I'm sharing my experience with writes to block requests mappings.



On 5/7/20 1:23 AM, 熊毓华 via lttng-dev wrote:


I want to know whether lttng trace data will provide mapping from file names to corresponding inode.

I refered some data parsed by babeltrace,and found that internal kernel tracepoints like writeback_dirty_inode_start、jbd2_submit_inode_data and lttng_statedump_vm_map can provide inode parameter.But I don’t know the meaning of these tracepoints mentioned above, and it seems to have little to do with the mapping we need.I want to know which tracepoint will record the mapping.

In addition, I found the get_inode_from_fd() function at lttng-uprobes.c.It seems to provide some hints, can this function provide the mapping information we want?If so, how should I use it to get the data.

Looking forward to your reply.



Yuhua Xiong
Lab for Internet and Security Technology
School of Computer Science and Technology
Zhejiang University
Hangzhou, 310007, P.R. China

lttng-dev mailing list lttng-dev@lists.lttng.org

[-- Attachment #1.2: Type: text/html, Size: 4699 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

lttng-dev mailing list

  parent reply	other threads:[~2020-05-11 16:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07  5:23 熊毓华 via lttng-dev
2020-05-07  5:23 ` [lttng-dev] " 熊毓华 via lttng-dev
     [not found] ` <>
2020-05-11 16:18   ` 熊毓华 via lttng-dev [this message]
2020-05-11 16:18     ` 熊毓华 via lttng-dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [lttng-dev] questions about mapping from file names to corresponding inode' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).