How does the length of a filename affect remaining storage space on a disk?

Question

How does the length of a filename affect remaining storage space on a disk?

I realize this is filesystem dependent. In particular I am thinking about the EXT series of file systems. I don't fully understand how inodes affect disk space and how the filename itself is stored. It's difficult to get relevant search results for this question too. That's why I'm asking here. On linux, the maximum file name length is usually 255 or 256 characters. When the file system is created, is that amount of space "reserved" for each and every file name? In other words, is disk storage not affected by the actual file name because the maximum is already used? Or is it more complicated than that?

Suppose, I have a file named "joe.txt" and rename it to "joe2.txt". Has the amount of available disk space decreased after this? What about longer names like "joe_version.txt" or "joe_original_version_with_bug_that_Jim_solved.txt"? I am worried about thresholds at 8, 16, 32, 64, etc characters. I will be storing millions of images. I have never bothered to worry about such an issue before so I'm not completely sure how this works.

Although EXT is the only filesystem I'm using, discussing FAT and others might be useful to somebody else that has a similar question.

Limann

Answer 1

On Linux (or more generally, Unix type filesystems) file names are stored in directory entry inodes, which contain a list of (filename, inode number) mappings for each file in the directory. My understanding is that for each filename there is reserved space for NAME_MAX characters. And indeed, on Linux NAME_MAX is 255.

So, to answer you question, when the file system is created there is no space reserved for file names, but once you create a file NAME_MAX bytes are reserved for the name. Moreover, for the directory inode, my understanding is that at least on ext2/3/4 space is allocated in disk block (4 KB, unless you're doing something very strange) granularity as needed. I.e. a directory takes up at minimum 4 KB (plus an entry in the parent directory inode), and if the list of (filename, inode) pairs doesn't fit into that 4 KB (minus other overhead, e.g. directory permissions), it allocates a new 4 KB block to continue the list, and so forth (ext2/3 uses an indirect block scheme, whereas ext4 uses extents).

Duteous

I was hoping more people would eventually comment on your answer and confirm it. I think it correct but I still don't know 100%. – Limann

Note that programs should not blindly assume that system wide NAME_MAX can be be actually used. Many filesystems do support that many bytes which may be totally different from characters with often used UTF-8 encoding. In addition, if the current mount is e.g. ecryptfs the actual limit may be more like 160 bytes. To get real limit, run getconf NAME_MAX /path/to/directory – Rotative

About the answer to the original question: the storage of filenames depends on filesystem and some filesystems may not reserve 255 bytes for every filename but compact the directory entries to fit as much as possible in one disk block. In addition, most filesystems are still designed for 512 byte disk blocks for historical reasons so if the change does fit in the existing block, no need space is needed. If the change doesn't fit, extra blocks are reserved until the data fits. – Rotative

Answer 2

FAT16 pre-allocates.

FAT32 uses a work-around to provide long filenames; as the filename becomes longer, additional directory file blocks are required to store the extra characters - and a directory file is a regular file, so this consumes additional disk space. However, the smallest allocation is one cluster, so unless the additional filename store exceeds the cluster boundary, no additional disk space is consumed from what you could otherwise have used.

I'm not offhand familiar with how filenames are handled in the UNIX type filesystems.

Mayenne