Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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
Thanks! Got it! – Anurag Peshne Mar 19 '13 at 16:32
Please fix "whether it's a file or a file". – l0b0 Mar 19 '13 at 16:33
up vote 6 down vote accepted

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.

share|improve this answer
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 posting your answer, you agree to the privacy policy and terms of service.

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