33

I find that under my root directory, there are some directories that have the same inode number:

$ ls -aid */ .*/

2 home/ 2 tmp/ 2 usr/ 2 var/ 2 ./ 2 ../ 1 sys/ 1 proc/

I only know that the directories' names are kept in the parent directory, and their data is kept in the inode of the directories themselves.

I'm confused here.

This is what I think when I trace the pathname /home/user1.

  • First I get into the inode 2 which is the root directory which contains the directory lists.
  • Then I find the name home paired with inode 2.
  • So I go back to the disk to find inode 2?
  • And I get the name user1 here?
psmears
  • 465
  • 3
  • 8
youxiao
  • 345

2 Answers2

45

They're on different devices.

If we look at the output of stat, we can also see the device the file is on:

# stat / | grep Inode
Device: 801h/2049d      Inode: 2           Links: 24
# stat /opt | grep Inode
Device: 803h/2051d      Inode: 2           Links: 5

So those two are on separate devices/filesystems. Inode numbers are only unique within a filesystem so there is nothing unusual here. On ext2/3/4 inode 2 is also always the root directory, so we know they are the roots of their respective filesystems.

The combination of device number + inode is likely to be unique over the whole system. (There are filesystems that don't have inodes in the traditional sense, but I think they still have to fake some sort of a unique identifier in their place anyway.)

The device numbers there appear to be the same as those shown on the device nodes, so /dev/sda1 holds the filesystem where / is on:

# ls -l /dev/sda1
brw-rw---- 1 root disk 8, 1 Sep 21 10:45 /dev/sda1
ilkkachu
  • 138,973
  • 1
    Thank you, now I get stat, useful for me, I'll learn to use it. – youxiao Dec 01 '17 at 17:32
  • 1
    For the record, all filesystems have some equivalent, even when they dynamically allocate inodes. For example, on BTRFS (which does dynamic inode allocation, in contrast to ext2/3/4's static inode tables), the particular inode value that is used like this is 256 (because everything lower is reserved for special entries in the metadata trees). – Austin Hemmelgarn Dec 01 '17 at 19:33
  • 1
    @AustinHemmelgarn, some filesystems such as FAT or ISO9660 don't have inodes in any meaningful sense of the word. The filesystem driver does some slight-of-hand to make it look to the rest of the system that they do. – Mark Dec 01 '17 at 21:12
  • @Mark: The only "meaningful sense of the word" per the standard that defines it is "file serial number [unique within the device]". Insisting on thinking of inodes as a particular on-disk data structure is about as backwards as thinking of ttys as mechanical teletypes. – R.. GitHub STOP HELPING ICE Dec 01 '17 at 21:27
  • 1
    @R.., I suppose by that definition the FAT filesystem has inodes, but the "file serial number" for a given file on a FAT filesystem isn't stable across mounts, or even over time on a single mount: if memory pressure causes a synthesized inode structure to be evicted from the cache, the file gets a new number the next time something requests its inode data. – Mark Dec 01 '17 at 22:31
  • @R.., so, what is that unique file serial number on FAT? The number of its directory entry (where pretty much all the data contained in a Unixy inode sit, along with the file name)? The number of its first data block (i.e. the pointer to the FAT chain also stored in the directory entry)? Something else? – ilkkachu Dec 02 '17 at 00:38
  • @ilkkachu: It's determined by the OS implementation that's providing a FAT-backed filesystem, not by the on-disk format. If I were implementing it I'd probably just use the cluster number of the start of the file. Synthesizing them in a way that they're lost and subject to change without remounting is buggy and non-conforming, and a waste of complexity since you can just use something simple and invariant like the cluster number. – R.. GitHub STOP HELPING ICE Dec 02 '17 at 02:43
  • @R.., well it has to be based on something that's on-disk, otherwise it's hard to make nonvolatile. I suppose the number of the first cluster works, if you're willing to force all files to occupy at least one (including zero-length files). I also thought the idea of the inode number is partly to be able to find the file information without a name, and you can't do that on FAT with just the cluster number. But then I'm not sure that needs to have anything to do with the st_ino that's visible to userland. – ilkkachu Dec 02 '17 at 11:09
  • @R.., as for conforming... I'm pretty sure FAT doesn't support a bunch of other features found in Unix standards either. – ilkkachu Dec 02 '17 at 11:10
26

The inode number of any given file is unique to the filesystem, but not necessarily unique to all filesystems mounted on a given host. When you have multiple filesystems, you will see duplicate inode numbers between filesystems, this is normal.

John
  • 17,011