Not-so-modern file system errors in modern file systems

On a system in heavy production use, using an underlying file system for metadata service, we see this:

kernel:  EXT4-fs warning: ext4_dx_add_entry:1992: Directory index full!

Ok, where does this come from? Ext3 had a limit of 32000 directory entries per directory, unless you turned on the dir_index feature. Ext4 theoretically has no limit. Well, its 64000 if you don’t use dir_index. Which we do use. Really the feature you want is dir_nlink.

  -O [^]feature[,...]
              Set or clear the indicated filesystem features (options) in  the
              filesystem.   More than one filesystem feature can be cleared or
              set by separating features  with  commas.   Filesystem  features
              prefixed  with  a  caret  character ('^') will be cleared in the
              filesystem\'s superblock; filesystem features  without  a  prefix
              character  or prefixed with a plus character ('+') will be added
              to the filesystem.
        The following filesystem features can be set  or  cleared  using
              tune2fs:
                   dir_index
                          Use  hashed  b-trees  to  speed  up lookups in large
                          directories.
                   dir_nlink
                          Allow more than 65000 subdirectories per directory.

So, obviously we have to turn this on, right? Before we do that, a quick tune2fs -l /dev/$dev to see what is currently in place

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype
                          needs_recovery flex_bg sparse_super large_file huge_file
                          uninit_bg dir_nlink extra_isize

So … its already on? And not working? Sometimes you gotta say whiskey tango foxtrot. Yet another reason to use xfs and ditch ext*. (n.b. our new SIOS v2 images will also let you build/use zfs file systems, by building installing the kernel module needed for this upon demand … so yes, we could use zfs as well)