From: Valient G. <vg...@po...> - 2004-09-03 08:27:44
|
On Fri, 2004-09-03 at 02:33, Paul Alfille wrote: > > My personal suspicion is that deeper thought might help people discover > inode-free algorithms. After all, inodes aren't intrinsic to > filesystems, they're just an implementation detail. I think you've missed the point. Inodes are not essential. However they are efficient. The kernel uses inodes as a unique identifier for a file, so that it doesn't have to constantly be doing hashtable lookups against a string key. Once you get beyond very simple filesystems, an implementation will need to maintain internal state information for each file. Currently the fuse kernel module identifies existing files to libfuse using inodes. Then libfuse does hash lookups and node traversal to get the filename from the inode. The filename is passed into the user library, where it is then likely to be used as a hash key to lookup the filesystems' internal file state (which involves first converting it back into an integer!). Since a filesystem needs only a unique key to identify which file is being accessed, it is inefficient to convert the inode (a perfectly valid unique identifier for the file) into a filename (a much longer unique identifier for the file) only to have to effectively undo this transformation in the user level code. So the reason people (including myself) are interested in inode-based interfaces is not the lack of deeper thought. We're trying to avoid transformations which are unnecessary because they add neither simplicity nor efficiency to our filesystems. However, for simple filesystems, I agree that the filename interface is simpler to use. Val |