Let's first understand inodes in layman's terms
By doing ... Our filesystem of choice for this demonstration will be EXT2 because it does not have a journaling mechanism and thus will be easy to corrupt for the purposes of demonstrating some inode related problems.
Let's create a "disk" image file:
$ truncate -s 10M myfilesystem
And format it
$ mkfs.ext2 myfilesystem
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 2560 4k blocks and 2560 inodes
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Notice the number of inodes ... and 2560 inodes ... This is the permanant maximum number for this filesystem on this disk partition ... You can create as many files(all kinds including directories) as that number(minus the filesystem's special inodes) but no more than that number on this filesystem.
Let's create a mount point and mount that filesystem:
$ mkdir mymount
$
$ mount myfilesystem mymount/
$
$ ls -la mymount/
total 24
drwxr-xr-x 3 root root 4096 May 8 14:24 .
drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 11 2.5K 1% /home/ubuntu/test/mymount
Notice the number of used inodes 11 ... These are called special inodes and reserved/used by default for the filesystem special predefined purposes... Let's use some more of them:
$ touch mymount/file{1..2}
$
$ ls -lai mymount/
total 24
2 drwxr-xr-x 3 root root 4096 May 8 14:33 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
12 -rw-r--r-- 1 root root 0 May 8 14:33 file1
13 -rw-r--r-- 1 root root 0 May 8 14:33 file2
11 drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 13 2.5K 1% /home/ubuntu/test/mymount
We created two files and used two more inodes and ended up with 11 + 2 = 13.
Let's free one of them:
$ rm mymount/file1
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 12 2.5K 1% /home/ubuntu/test/mymount
That's normal 13 - 1 = 12 used inodes and the one we just freed will be reused when needed ... inodes are recyclable.
That is under normal conditions ... But, what if we in another shell continuously open and use a file:
$ tail -f mymount/file2
-
Then go back to our original shell to delete that file then immediately ungracefully unmount the filesystem:
$ rm mymount/file2 && umount -l myfilesystem
$
$ ls -lai mymount/
total 8
6425 drwxr-xr-x 2 root root 4096 May 8 14:29 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
Then, mount it again:
$ mount myfilesystem mymount/
$
$ ls -lai mymount/
total 24
2 drwxr-xr-x 3 root root 4096 May 8 14:44 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
11 drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 12 2.5K 1% /home/ubuntu/test/mymount
Notice how although the file has been actually deleted but it's inode is not freed up ... That is a filesystem corruption "simulation" ... Let's unmount and check:
$ umount myfilesystem
$
$ e2fsck myfilesystem
e2fsck 1.46.5 (30-Dec-2021)
myfilesystem was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 13 has zero dtime. Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences: -13
Fix<y>? yes
Free inodes count wrong for group #0 (2548, counted=2549).
Fix<y>? yes
myfilesystem: ***** FILE SYSTEM WAS MODIFIED *****
myfilesystem: 11/2560 files (0.0% non-contiguous), 170/2560 blocks
Let's close the other shell and mount again and check:
$ mount myfilesystem mymount/
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 11 2.5K 1% /home/ubuntu/test/mymount
Now you know the basics of how inodes are used ... And some of what could go wrong with them to trigger a filesystem check and how ... The same can happen while plugging/unplugging a disk or when the system looses power suddenly as files(especially system files) are created/deleted/updated constantly by system processes ... It is a bit less in case of directories as it's not normally possible to hold a directory open by a process as they don't have a handle like ordinary files, but corruption can happen with directory inodes if the above happened while their meta data is being updated/modified and also, although rare, it can happen when the filesystem looses access to certain blocks due to a failing/deteriorating disk drive.
However, most issues with inodes can be easily automatically fixed by filesystem checking utilities.
Back to your question
There are times, however, when those utilities loose path and don't know how to fix an issue with inodes especially with directories that don't have valid readable meta data as among the methods those tools use to fix corruption with inodes is actually meta data that identify directories contents, parents ... etc.
The screenshot you included makes it a bit hard for me to read and copy text from ... However, what you appear to have is an inode 4732284 (under /usr/src/linux ... /net/ ...) that is labeled as a directory in the filesystem but, lacks the usual metadata describing it's relation to its parents which makes it orphaned and it doesn't occupy the usual one block space e.g. 4k but rather occupies 0 space and hence the NULL ... While on most filesystems files are allowed to be null/0 in size, directories are not, please see this post and this post for more details.
This type of problem, if it doesn't increase dramatically which might indicate a failing disk drive/bad and deteriorated blocks, is not a big issue and should be harmless ... To get rid of it the easy way, You just need to use it ... i.e. create a file in that directory then remove it to update its meta information so that it goes back to using a full filesystem block size and look a bit normal ... That directory should be easy to spot as it will show 0 size in the output of e.g. ls -la and after you use it, it should show the usual block size e.g. 4klike other directories on the same filesystem ... If that is not enough to bring it back to normal, then shake it more with e.g. setting its ownership e.g. chown root:root or changing its permissions e.g. chmod 755 until ls -la shows some size other than 0 for that directory.
Then unmount the containing filesystem and run the filesystem checking utility again and it should fix it this time.
That should work but, if it didn't work, then you have two alternatives ... Either using a filesystem debugger like debugfs to fix/delete that inode's entry manually or alternatively backing up your data and reformatting that disk partition.
Technical references:
