4 ms·

They definitely aren't unique even without reboots. Postfix uses the inode number as a queue id. At $dayjob we've seen reuse surprisingly quickly, even within a

They definitely aren't unique even without reboots. Postfix uses the inode number as a queue id. At $dayjob we've seen reuse surprisingly quickly, even within a few hours. Which is a little annoying when we're log spelunking and we get two sets of results because of the repeating id! (there is now a long queue id option which adds a time component)

amiga386 1y ago
...but it's unique while the file exists, right? The combination of st_dev and st_ino from stat() should be unique on a machine, while the device remains mounted and the file continues to exist. If the file is deleted, a different file might get the inode, and if a device is unmounted, another device might get the device id.
- the_mitsuhiko 1y ago
  > The combination of st_dev and st_ino from stat() should be unique on a machine It should, but it seems no longer to be the case. I believe there was an attempt to get a sysctl flag in to force the kernel to return the same inode for all files to see what breaks.
- AndrewDavis 1y ago
  Yes! It's reusable, but not duplicated.
- londons_explore 1y ago
  > ...but it's unique while the file exists, right? I don't think all filesystems guarantee this. Especially network filesystems.
  - the_mitsuhiko 1y ago
    It's effectively impossible to guarantee this when you have a file system that unifies and re-exports. Network file systems being an obvious one, but overlayfs is in a similar position. Even if inodes still work nowadays they will eventually run into issues a few years down the line.
    - account42 1y ago
      Then unifying file systems is not something that POSIX support and a POSIX system shouldn't do it unless it can somehow map inodes with POSIX semantics. E.g. for a network mount spanning multiple remote filesystems you could also have multiple st_dev locally.
  - amiga386 1y ago
    That's a problem for programs that do recursive fs descent (e.g. find, tar) because they use st_dev and st_ino alone for remembering what directories they've been in. They can't just use the absolute path, because symbolic links allow for loops. find: * https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/find/sharefile.c#n51 https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/fi... * https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/find/pred.c#n900 https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/fi... tar: * https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/create.c#n1413 https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/crea... * https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/names.c#n905 https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/name... * https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/incremen.c#n524 https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/incr... In particular, I'm intrigued by the comment in the last link: /* With NFS, the same file can have two different devices if an NFS directory is mounted in multiple locations, which is relatively common when automounting. To avoid spurious incremental redumping of directories, consider all NFS devices as equal, relying on the i-node to establish differences. */ So GNU tar expects an inode to be unique across _all_ NFS mounts...
    - the_mitsuhiko 1y ago
      You are not wrong, but the issues with tar are well known. Linus himself had this to say [1]: > Well, the fact that it hits snapshots, shows that the real problem is just "tar does stupid things that it shouldn't do". > Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history. > An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed. You might still get away with it most of the time today, but it's causing more and more issues. [1]: https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04127.html https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04127.html
      - amiga386 1y ago
        That sounds like blaming userspace. If it's not the 1970s anymore, then update the POSIX standard with a solution that works for all OSes (including the BSDs) and can be relied upon. Definitely don't suggest a Linux-only solution for a Linux-only problem.
koverstreet 1y ago
The combination of st_ino and the inode generation is guaranteed to be unique (excepting across subvolumes, because snapshots screw everything up). Filesystems maintain a generation number that's incremented when an inode number is being used, for NFS. Unfortunately, it doesn't even seem to be exposed in statx (!). There's change_cookie, but that's different. If anyone wants to submit a patch for this, I'll be happy to review it.
- formerly_proven 1y ago
  We tried to handle hard-links correctly ~ten years ago in a backup tool and even back then it was "well obviously you have to use (dev, ino, gen), not just (dev, ino), that's moronic!" and we're like... "so where do we get the generation number?". There actually was an ext4 ioctl to do so, but at least back then it was only implemented by ext4. IME it's a pretty consistent pattern with unixy/linux filesystems that what you can do with the normal APIs is wrong/incorrect/full of bugs and race conditions, while what you're "obviously supposed to do" instead is some absurd fs-specific concoction or just straight up isn't exposed by the kernel.
  - koverstreet 1y ago
    Tell me about it. Getting proper APIs is just an enormous hassle, we're bad about bikeshedding things to death. Although it has gotten somewhat better.

amiga386 1y ago

...but it's unique while the file exists, right? The combination of st_dev and st_ino from stat() should be unique on a machine, while the device remains mounted and the file continues to exist. If the file is deleted, a different file might get the inode, and if a device is unmounted, another device might get the device id.

the_mitsuhiko 1y ago
> The combination of st_dev and st_ino from stat() should be unique on a machine It should, but it seems no longer to be the case. I believe there was an attempt to get a sysctl flag in to force the kernel to return the same inode for all files to see what breaks.
AndrewDavis 1y ago
Yes! It's reusable, but not duplicated.
londons_explore 1y ago
> ...but it's unique while the file exists, right? I don't think all filesystems guarantee this. Especially network filesystems.
- the_mitsuhiko 1y ago
  It's effectively impossible to guarantee this when you have a file system that unifies and re-exports. Network file systems being an obvious one, but overlayfs is in a similar position. Even if inodes still work nowadays they will eventually run into issues a few years down the line.
  - account42 1y ago
    Then unifying file systems is not something that POSIX support and a POSIX system shouldn't do it unless it can somehow map inodes with POSIX semantics. E.g. for a network mount spanning multiple remote filesystems you could also have multiple st_dev locally.
- amiga386 1y ago
  That's a problem for programs that do recursive fs descent (e.g. find, tar) because they use st_dev and st_ino alone for remembering what directories they've been in. They can't just use the absolute path, because symbolic links allow for loops. find: * https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/find/sharefile.c#n51 https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/fi... * https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/find/pred.c#n900 https://cgit.git.savannah.gnu.org/cgit/findutils.git/tree/fi... tar: * https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/create.c#n1413 https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/crea... * https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/names.c#n905 https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/name... * https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/incremen.c#n524 https://cgit.git.savannah.gnu.org/cgit/tar.git/tree/src/incr... In particular, I'm intrigued by the comment in the last link: /* With NFS, the same file can have two different devices if an NFS directory is mounted in multiple locations, which is relatively common when automounting. To avoid spurious incremental redumping of directories, consider all NFS devices as equal, relying on the i-node to establish differences. */ So GNU tar expects an inode to be unique across _all_ NFS mounts...
  - the_mitsuhiko 1y ago
    You are not wrong, but the issues with tar are well known. Linus himself had this to say [1]: > Well, the fact that it hits snapshots, shows that the real problem is just "tar does stupid things that it shouldn't do". > Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history. > An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed. You might still get away with it most of the time today, but it's causing more and more issues. [1]: https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04127.html https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04127.html
    - amiga386 1y ago
      That sounds like blaming userspace. If it's not the 1970s anymore, then update the POSIX standard with a solution that works for all OSes (including the BSDs) and can be relied upon. Definitely don't suggest a Linux-only solution for a Linux-only problem.

koverstreet 1y ago

The combination of st_ino and the inode generation is guaranteed to be unique (excepting across subvolumes, because snapshots screw everything up). Filesystems maintain a generation number that's incremented when an inode number is being used, for NFS. Unfortunately, it doesn't even seem to be exposed in statx (!). There's change_cookie, but that's different. If anyone wants to submit a patch for this, I'll be happy to review it.

formerly_proven 1y ago
We tried to handle hard-links correctly ~ten years ago in a backup tool and even back then it was "well obviously you have to use (dev, ino, gen), not just (dev, ino), that's moronic!" and we're like... "so where do we get the generation number?". There actually was an ext4 ioctl to do so, but at least back then it was only implemented by ext4. IME it's a pretty consistent pattern with unixy/linux filesystems that what you can do with the normal APIs is wrong/incorrect/full of bugs and race conditions, while what you're "obviously supposed to do" instead is some absurd fs-specific concoction or just straight up isn't exposed by the kernel.
- koverstreet 1y ago
  Tell me about it. Getting proper APIs is just an enormous hassle, we're bad about bikeshedding things to death. Although it has gotten somewhat better.