file system check for ext4 file systems
 

I know if you have an ext2 or ext3 file system, you can run e2fsck to have it clean up the file system. But what do you run if your file system is ext4?

e2fsck still applies.

Awesome, thanks. Wasn't sure if they replaced it with something newer or not. I'm glad they didn't, since e2fsck is one of the few things I think I'm actually good at running in Linux hahaha.

All are the same prog.

Oh! cool, pretty clever how you figured that out too!

That was just to show the result. The way to find that out is:

Oh ok. I'm not sure I really understand what all that means or how it actually proves it, but I feel better knowing they are all one in the same.

It shows that all 5 names map to the same inode number, 4528, i.e., there is just one physical file on the disk, and those 5 directory entries map to that same file. The ls command shows the inode number (which I marked in red) for the file I asked it about, and then the find command looks in the /sbin directory for entries that map to that inode number.

Oh, ok. thanks again for explaining! now i know this is going beyond the original post, but can only one file occupy an inode, so that's why that proves it? and those other ones are more like links/pointers to what's really e2fsck?

find /sbin -samefile /sbin/e2fsck

is easier.

The inode is what defines the file (singular). The inode contains all the metadata (ownership, permissions, timestamps, ...) and the file system block numbers for accessing the file's data.

And, that file isn't "really e2fsck" any more than it is "really" any of those other names. A directory entry is just a pointer to an inode (for convenience, some other information, such as file type (ordinary, directory, device, FIFO, ...) may be kept there as well), and there can be more than one directory entry pointing to a given inode. Those directory entries are called "hard links," and in order to be located by name a file need to have at least one. One of the fields in the inode is the hard link count, and it is when that count goes to zero (and the file is not currently in use by any process) that the inode is marked "free" and the file's data blocks are returned to the free pool.

Is the behaviour the same regardless of what name is used?

Without knowing the program, that is uncertain. By convention, the name by which a program is invoked is placed in argv[0] (available as $0 in a shell script). Programs can, and some do, change their behavior depending on the name in argv[0]. An example would be /usr/bin/pgrep and /usr/bin/pkill. I believe that e2fsck actually looks at the filesystem it is asked to check and does not depend on how it was invoked, and just now running fsck.ext4 successfully on an ext3 filesystem seems to confirm that.

Note also that an inode num is only unique per filesystem/partition; this is why hard-links cannot cross partitions (unlike soft links which just contain a dir path+filename)

Several aspects of hard link semantics would break if the link crossed file system boundaries, issues that become more apparent when you consider that one of those file systems might not be currently mounted, or perhaps physically removed and connected to an independent system. Trying to fsck one of those divorced file systems comes to mind.