Hii

I am new to linux kernel. I want to get file name from inode number by modifying linux kernel source code.. I know that outside the kernel we can use lsof command to get filename from inode number but my question is how to do the same in kernel source code if I have inode pointer. Can anyone suggest me something?

There can be many names for the same file. Files can also exist with no name. So, first check the link count in the inode - that's the number of names.

The problem then is that you don't know where the names are stored. They can be in any directory in the same filesystem. You would have to search the entire filesystem and check all directories if they contain a name for this file.

In user space you can do this with a find command:
I wonder if modifying the kernel to do the same thing provides any value. Perhaps maintaining a cache of all directories to speed this up; at each mkdir, rmdir, creat, unlink and whatever other system call, you would have to manage that cache.

The simple answer is that you can't.

First, inode numbers exist in nearly every filesystem (and simulated where they don't)... Every mount duplicates those inodes, so inode 1000 from /home is not the same as the inode 1000 from /, nor is it the same for inode 1000 from a CD/DVD/flash/...

Next, a name for a file only exists in a directory (which itself is basically just a file with name,inode pairs). Since the name is only a map to an inode, there can be as many names mapped to the same inode number as there are entries in a directory (there is a limit, something around 65535 - an unsigned 16 bit value, the limited by the inode data structure). A file is not deleted until that count in the inode structure goes to zero, then the data blocks and metadata blocks are deallocated, and the inode is marked unused.

If you look, a directory itself ALWAY has two links (and two names) - a given name->inode entry in a parent directory, AND a "."->inode entry in the directory itself.

Names aren't a file... Only the inode number within a filesystem. To have a fixed name, you have to use a device-id,inode pair. Unfortunately, that "device-id" is not unique. It is assigned every time a device is plugged in - and unique only while it is plugged in. This is why "symbolic" links use a pathname to point to files. They are not name->inode map, they are name -> pathname map (which change the file being pointed to depending on the current filesystem mount being used...).

additionally I would say kernel works with inodes and does not really care about the "rest", so does not really care about the type of the filesystem (or anything related).
What you want to do is (more or less) embedding the filesystem driver/handler into the kernel (which one[s]??).

From the other hand can you tell me: how does it work?

1 members found this post helpful.

The OP wants to hack the kernel, s?he can do whatever they like.
There is a reason (several) why this is a *bad* idea, but it should be do-able. I do wonder how much of the appropriate code the OP has actually read though.
The VFS is used to abstract out the specifics of filesystems as far as the kernel is concerned - might be a good place to start.

:-) The VFS doesn't track names-> inodes. It only tracks inodes. For a given a name it calls the filesystem to locate an associated inode. There is nothing to take an inode and find a name.

Besides adding a new function to VFS, you also have to add the function to every filesystem...

And changing a filesystem will also fail - the return value has to return a varying sized LIST of names. Anywhere from one name, to a worst case 65535. And each name COULD be as long as 255 bytes... And if the filesystem is supposed to store these names, then the inode will have to be able to store that data... And modify the fsck process for each filesystem -- and all the tools (including dump/restore). If you DON'T store the list, then the filesystem will be locked up while it searches for all possible names assigned to an inode (which is all find -inum is doing).

Not gonna happen - as a practical matter.

I have used filesystems that did this (Files 11 on VMS)... But to do it they had to limit the number of links to a file (the inode link in UNIX/Linux) to a maximum of ONE. And any file with more than one caused the filesystem check to report that it was corrupted.

For files that are currently open, that information is available, somewhere, even for files that have been subsequently unlinked. The lsof command or /proc/{PID}/fd/* does show, even for unlinked files, the path by which a file was opened, and that path does reflect changes by a subsequent rename(2) of that file (but not if the change was due to adding a hard link and deleting the original -- that still shows as "original/path (deleted)").

You're still doing a search to find it -- searching through the kernel structures for all open files, or walking through the filesystem for files not currently open.