My VFS design

[piranha]

I just wanted to run this by the smarted people than me here.

My VFS uses inodes to represent all things (character and block devices, directories, files). In each inode is a pointer to the parent inode, a dummy child inode, and the next inode in the current level/directory.

The dummy child is present only in a directory. If the inode doesn't represent a directory, that pointer is 0. The dummy child's next pointer is 0 if the directory is empty, and points to the first visible file if one exists. Therfore, adding files is just manipulating a linked list.

The inode also has a 'mountpointer' pointer. That points to the root inode of a filesystem when it gets mounted. Simply, if the inode is a mountpoint, mount_ptr is set. Otherwise it's not a mount point.

The lookup function looks up file 'name' inside inode 'i'. It loops through i->child->next....->next... until it reaches the end of the linked list. If it finds the file, it returns the inode.

One thing that I realized was "Well, this works if all the filesystems are in memory...but in a large FS on disk this could become a problem. So I added a flag to struct inode. The 'dynamic' flag is set if some of it's child inodes could be on disk. If it can't find them through normal lookup, it calls the inode's lookup function. Thus a filesystem must only load a root inode and a dummy child. This seems like it will work in my mind.

My question is, are there any problems you might foresee? I may post more stuff later when I get time (kinda outta time right now...)

-JL

[xyzzy]

One thing that I realized was "Well, this works if all the filesystems are in memory...but in a large FS on disk this could become a problem. So I added a flag to struct inode. The 'dynamic' flag is set if some of it's child inodes could be on disk. If it can't find them through normal lookup, it calls the inode's lookup function. Thus a filesystem must only load a root inode and a dummy child. This seems like it will work in my mind.

My question is, are there any problems you might foresee? I may post more stuff later when I get time (kinda outta time right now...)

This is what I do in my VFS, except I do all lookups like this, not just if a flag is set. When a filesystem is mounted, the FS's mount function will set stuff up in the root node of the mount. When looking up a path, the VFS first checks through the nodes already in memory. If it is found in memory, the existing node's reference count is increased. If it cannot be found in memory, it will call the FS's lookup function to find the node, and then insert it into the tree (with the reference count set to 1).

Each node has a reference count, as I mentioned before. It is increased when a lookup finds a node, and decreased when something calls vfs_node_free() to say that it is no longer using the node. If the count reaches 0, a function is called in the FS backend to clear up anything it may have allocated for the node, and then it is freed from memory. This means that only the nodes that are being used somewhere are actually kept in memory.

[piranha]

When calling the function to decrease the ref count (and maybe call the function to cleanup the inode), should it decrease the ref count of the parent inodes too?
Edit: And in the same idea, should the ref count each and every inode that lookup goes through be incremented? Or just the final inode?

-JL

[xyzzy]

When calling the function to decrease the ref count (and maybe call the function to cleanup the inode), should it decrease the ref count of the parent inodes too?
Edit: And in the same idea, should the ref count each and every inode that lookup goes through be incremented? Or just the final inode?

-JL

When a new node is added to the tree while looking up from disk, the parent's reference count is increased so that it doesn't get freed while the child is around. When a vfs_node_free() call on the child causes it to be freed, it recursively calls itself on the parent to decrease it's reference count and free it as well if necessary, and so on.

[piranha]

Thanks, thats what I thought.

-JL