3

I have several questions on how inode number is used in linux filesystem. These questions may be related but for clearness I will ask them one by one.

Q1: Take EXT2/3 for example, from "Design and Implementation of the Second Extended Filesystem" I know that there are inode tables in block groups, and I know inode presents file, but what if there are too many files but the inode numbers are not enough? My best guess is that filesystem does nothing if all its inode numbers were exhausted. And if some file get deleted later, its inode may be recycled.

Q2: I run "df -i" on my Linux server and I get this:

Filesystem            Inodes       IUsed   IFree      IUse% Mounted on    
    /dev/sda1          1313280    7853 1305427    1%     /
    devtmpfs                   0       0       0              -       /dev
    tmpfs                 525298       4  525294        1%    /dev/shm
    /dev/sda2              65808      50   65758       1%    /boot
    /dev/sda5            1313280     146 1313134    1%   /opt
    /dev/sda6             655776      37  655739      1%   /tmp
    /dev/sda7             655776    5219  650557    1%   /home
    /dev/sda8            1313280     840 1312440    1%  /var
    /dev/sda9             655776   36529  619247    6%  /usr
    /dev/sda10              6432      11    6421        1%  /crash
    /dev/sda12            135488      11  135477     1%  /usr/local/instances
    tmpfs                 525298       3  525295    1% /var/run/xenstored
    tmpfs                 525298       3  525295    1% /var/lib/xenstored
    tmpfs                 525298       3  525295    1% /var/lib/xend/socket
    tmpfs                 517536       3  517533    1% /var/run/libvirt/socket

I see that each filesystem has its own inode counts and these filesystems (like devtmpfs and tmpfs) are all mounted to root file system. I guess each filesystem have their own inode tables, but are inode numbers of different filesystems distributed in different ranges, like root filesystem is [0, N] and tmpfs is [N+1, M]?

If inode numbers of different filesystems are in different ranges (which I don't think so), how filesystems make an agreement on range division?

If inode numbers of different filesystems are generated based on the same rule (like all start from 0), can different filesystems conflict if we mount them together? As I know, inode presents files in running OS, what the OS will do if a file in root filesystem has inode number N and another file in another filesystem (like tmpfs) also has the inode number N?

PS. I'm kind of new to Linux and I'm not coming from a English-speaking country, sorry for if I didnot make clear expression. Thanks in advance.

xanpeng
  • 173
  • 1
  • 4
  • This sounds like a better question for http://s.tk/unix. – Matt Ball Nov 08 '11 at 03:30
  • Try asking on one of the the "unix" or "ubuntu" forums. You will get better answers :-}. We are just coders here and generally don't care what happens after "System.IO.WriteLine()". – James Anderson Nov 08 '11 at 04:35
  • This is one of those questions where it's hard to say. I would say it belongs here since it's an interesting implementation detail about Unixes in general. – Omnifarious Nov 08 '11 at 04:41
  • Please only ask one question at a time. – user229044 Nov 08 '11 at 04:43
  • @meagar - All of the questions being asked are very related to each other and they have a single simple answer. – Omnifarious Nov 08 '11 at 04:45
  • @omnifarious Those are the rules, I didn't write them. – user229044 Nov 08 '11 at 04:46
  • @meagar - Then maybe you should request that about 75% of the questions I asked be deleted too if you're going to pick on this one for a nitpicky rules violation. If you want to go on a crusade against questions that have more than one '?' mark in them you'd end up erasing a non-trivial percentage of stack overflow. – Omnifarious Nov 08 '11 at 04:51
  • @Omnifarious Pretty sure I was being polite and educating a new 1-rep user, while you are raving and crusading against what you perceive as nitpicking. How's that crazy persecution complex working out for you? Keep it up though, you're really helping make Stack Overflow better for us all! – user229044 Nov 08 '11 at 04:53
  • @meagar - Thanks for your suggestion. I'll be more careful on asking quetions :) – xanpeng Nov 08 '11 at 05:00
  • @meagar - *nod* I get irritated by how easily questions are closed here. I would say about 15% of the questions I see closed don't really deserve to be. – Omnifarious Nov 08 '11 at 05:05
  • @JamesAnderson - Maybe you are right, we don't have to know details all the time, but sometimes I am just eager to know WHY :) – xanpeng Nov 08 '11 at 05:27
  • Seems like a good question, that could have substantial applicability to developers. Anyone writing filesystem-level utilities (backup, change notification, synchronization, etc) would want to know things like this. – Phil Miller Nov 08 '11 at 05:35

1 Answers1

5

The full unique identifier for a file is (st_dev, st_ino). This means that inode numbers do not have to be unique across filesystems and every file is still uniquely identified.

This is why you cannot have hardlinks that cross devices. Directory entries only contain an inode number, not a device number. So directory entries can only refer to files on the same filesystem as the directory is on.

Even if you added a device field to the directory entry, it would be meaningless and device numbers can change when you add or remove drives and only refer to a particular device while a system is running. Also, how would you uniquely number all of the devices in the entire world. With USB drives, for example, you can take a given device from machine to machine. How would you ensure the device numbers stayed the same so the links still worked?

Lastly, not all filesystem types have a fixed quantity of inode numbers. reiserfs and (I believe) btrfs dynamically allocate new inodes as needed, and so the total inodes field of the filesystem doesn't really reflect any sort of useful value.

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
  • `(st_dev, st_ino)` is quite helpful information here, and also the explanation of hardlinks. Thanks. – xanpeng Nov 08 '11 at 05:23