This question is extension to How are directories implemented in Unix filesystems?

I'm aiming to implement basic filesystem: After reading inode number and name we come to know Name of file and hence we can list directory contents but we can't determine type of entry: whether it's another directory or a file. If there are 1000 entries in directory then reading 1000 inodes just to determine whether it is file or directory looks too silly.

Am I missing something here or it is this way only?

  • I don't think I understand your question. Why is this "silly"? – Mat Mar 19 '13 at 16:23
  • suppose there are 1000 entries..user will probably click just one of the entry. So reading 1000 inodes from hard disk to determine whether its a file or directory seems too inefficient. – Anurag Peshne Mar 19 '13 at 16:25
  • I think I understand now. If you're the one writing the filesystem, you're free to add any metadata you want anywhere you want, you don't have to store only the inode/filename pair. But beware of links and keeping that metadata in sync everywhere. – Mat Mar 19 '13 at 16:30
  • Please fix "whether it's a file or a file". – l0b0 Mar 19 '13 at 16:33
  • @AnuragPeshne in response to "user will probably click just one of the entry". When a user make a call to /dirA/subdirA/subsubdirA/fileA you do not need to verify that the subdirB and all the other 998 subdirs are all dirs. So it is not inefficient. You just need to check that subdirA is a directory and if it contains subsubdirA. – Huygens Mar 19 '13 at 16:47

Basically: it is your decision

If by "UNIX File System" you mean UFS, then a parent directory inode does not cache the file types, it only contains the files and corresponding inodes. Source: UFS File Systems (PDF, see chap 15.2.2)

This might not be the case for all file systems, it is a design choice. And for your file system it could be your design choice.

For the silliness of this choice, I would disagree. Think how many times would the system have to check for the types of files under a directory? You have to balance the frequency of a ls -l command with the extra space that caching the information in the inode would take.
If your file system is a cluster-like (e.g. glusterfs) or network-like (e.g. nfs) one, then this could be a good idea due to the possible latency of accessing all the inodes. On local storage this could be less of a concern.
In addition what is your file system trying to achieve? If it is designed to be efficient with directories that contains each thousands of files, then it could be worth considering caching the file types, if it is designed to be lean with the smallest footprint then caching could not be avoided.

Note about ext2, 3 and 4 and the filetype feature

It seems that ext2-4 can do exactly what you have in mind. It can cache the file types in the directory entry. This is only active with the feature filetype as filesystem creation time. When this feature is used, then ext4 uses a different structure for the directory entry which can have a cache of the file types. This applies to ext2 and ext3 as well.

| improve this answer | |
  • 2
    Besides the space overhead there is the disadvantage of maintaining the same information in multiple places. Once a file is open it is not the file name which is locked, it is the inode. A file can be linked in potentially many directories. If the meta-data is stored in the directory only (as opposed to on the directory AND in the inode) then what to do when two hard links have conflicting meta-data? – Johan Mar 19 '13 at 20:12
  • @Johan you are absolutely right, good point! – Huygens Mar 20 '13 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.