How can i trace Inode structure and modify it in UNIX kernel?
We want to change the inode structure in the sense that we want to add a new field to the inode data structure. So we want to know how and where to trace inode
What is your intention here? If you need this to actually get stored on disk you'll need to change a lot more than a structure.
... and which UNIX kernel?
Regards and welcome to the forum,
Alister
I don't think you can add a new field in inode structure, but you can use "debugfs" to view/change values of existing fields.
We are currently working on OpenSolaris so ZFS is the filesystem we are aiming at....actually we came across the inode data structure and thought of a vital functionality which was not implemented...so we took this up as a project...
now we are looking for your help for the same...Any ideas how to add a field to the inode...
Our main purpose right now is to trace the inode structure so that we can make changes to it...
Please HELP!!
Why don't store the metadata in a file/db in the file system?
OS : freebsd 8.2 release
As of now we have understood that any program uses struct stat structure to store temporary inode info and display it. The struct stat structure gets info from struct inode (defined in inode.h) which in turn gets info from struct dinode. The struct dinode is (or may be, I am not sure) is the actual physical representation of the inode structure.
I also tried studying ls.c source code. I found that it uses another important structures struct FTS and struct FTSENT for traversing the file system hierarchy using functions defined in fts.c. Now the problem is that fts.c uses systemcalls like fstat() and open() for accessing inode information
I'm trying to find how the information is retrieved from dinode and printed on the console or to the file. Once I know how it is retrieved, I'll try to add a field to dinode structure last_modified_by i.e it would have the username who lastly modified that file. I'll probably try to modify ls.c also to display information on console.
I think the path for the system calls are two fold:
- Filesystem Independent system calls present in /usr/src/lib/libstand
- Filesystem Dependent system calls present in /usr/src/lib/libstand/<file_system.c>
I have read /usr/src/lib/libstand/stand.h which I think is the periphery of Platform Independence. I t has a structure called struct fs_ops which has function pointers for system calls like *open(), *stat(), *fstat() etc.
These function pointers are made to point to actual system calls from different Platform Dependent file systems like ext2fs , ufs etc.
This is done by the open system call ( by reading from the struct open_file files] and struct fs_ops *file_system[).
I think if we want to add thi field for a particular file system, then I should try to make changes in file system C files like ufs.c and vfs.c ( and so on ...)
Now I was thinking that modifying already implemented file systems is a messy thing. So, I was planning to make my own file system. This file system code will only include the necessary fs_ops (File system Operations i.e. system calls) and putting the appropriate pointers in stand.h. Am I thinking right?
I read an IBM Developer Forum for FUSE which explained how to create a File System in User Space which explained something very similar. The link is as follows:
http://www.ibm.com/developerworks/linux/library/l-fuse/
Can you please suggest if I am on the right track or not. And also can you suggest some links I can read, that might help me for the same( ie For creating or modifying the file system)
Well, for starters, it'd help if you started answering any of our questions.
If you want to make these changes persistent on disk, it's not just the inode you're wanting to modify, but the entire kernel and filesystem... A bit of a tall order, and modifying the inode without that is a pretty tall order by itself.
There may be better ways to monitor what you want without modifying the kernel itself, like tracing the kernel.