[Top] [All Lists]

Re: any way to work backwards from xfs_inode_t to a filename?

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: any way to work backwards from xfs_inode_t to a filename?
From: Chris Friesen <chris.friesen@xxxxxxxxxxx>
Date: Thu, 16 May 2013 09:44:57 -0600
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, Alex Elder <elder@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130515230459.GY812@xxxxxxx>
References: <5194050B.7010401@xxxxxxxxxxx> <20130515221000.GX812@xxxxxxx> <51940A08.2040306@xxxxxxxxxxx> <20130515230459.GY812@xxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16
On 05/15/2013 05:04 PM, Ben Myers wrote:

On Wed, May 15, 2013 at 05:19:52PM -0500, Eric Sandeen wrote:
On 5/15/13 5:10 PM, Ben Myers wrote:
1) do_unlinkat() has the filesystem path, but iput() returns void.
Is there any way for me to add instrumentation to xfs_inactive() to
work backwards from the xfs_inode_t pointer to print out a path to
the file being deleted?

Use VFS_I to get to a 'struct inode' and from there you can look at the
dentries on i_dentry list and traverse back through the path by looking at
d_parent.  Might be easier to just print the path in do_unlinkat?

or just print out the inode nr (i_ino) and do a find -inum after the fact.  :)


Dave pointed out that you might not be able to get to the inode at this point
in the lifecycle.  Apologies if I posted misinformation.  ;)

Thanks guys,

I'm headed away for a few days so it'll be a while before I can dig into this again, but this should give me a good start.


<Prev in Thread] Current Thread [Next in Thread>