The ext file system uses many 32bit counters. Admittedly, version 4 fixed most of that (when formatted with the correct options).

In a similar vein, inodes can run out. On most conventional Linux file systems, inode numbers are 32 bits.

For many, this is not going to be a practical problem yet, as real volumes will run out of usable space before exhausting 2^32 inodes. However, it is theoretically possible with a volume as small as ~18 TiB (using 16 TiB for 2^32 4096-byte or smaller files, 1-2 TiB for 2^32 256- or 512-byte inodes, plus file system overheads).

Anticipating this problem, most newer file systems use 64-bit inode numbers, and some older ones have been retrofitted (e.g. inode64 option in XFS). I don't think ext4 is one of them, though.

It does happen in prod. Usually due to virtual FSes that rely on get_next_ino: https://lkml.org/lkml/2020/7/13/1078

That method is wrapping and not checking for collisions? I would not call that a problem of running out then. It's a cheap but dumb generator that needs extra bits to not break itself.

There is a limit on reliable usage of the FS. Call it what you want. The user doesn't particularly care.

What I'm trying to say is that the problem you're describing is largely a separate problem from what kbolino is describing. They are both real but not the same thing.

... which also caused it's own issues with 32-bit applications without large file support that now fail to stat those files on 64-bit inode filesystems.

IPv4, technically, is another 32-bit bomb, but that's not Linux-specific.

I wouldn't call this a bomb at all. Bombs are events, not processes.

Resource contention for IPv4 has been around for a long time, with a number of workarounds and the ultimate out of supporting IPv6. There has been, to date, no moment of crisis, nor do I expect one in the future.

It will just get steadily more annoying/expensive to use IPv4 and IPv6 will relieve that pressure incrementally. We're at least two decades into that process already.

Two decades in, and IPv6 is still the more annoying option.

I wish they were less ambitious and just increased address sizes when designing ipv6.

If more people bothered to configure IPv6 instead of complaining about it, V4 would be a thing of the past already.

A lot of people don't have a choice.

Just last(?) year I finally switched to an ISP whose equipment supports IPv6. But I still can't actually use it since my wifi router's support for IPv6 somehow fails to talk to the ISP equipment.

Hm, there's a firmware upgrade ... (installs it) well, re-trying all those options again, it looks like one of them lets it finally work now. The others (including the default) still fail with arcane errors though!

Interesting that the IPv6 adoption still differs so wildly for consumer connections aroundthe world. ISPs here have started to not give you a real public IPv4 address unless you ask for it. I expect it to become a paid option soon enough (main reason normal people ask for it is to connect to shitty IPv4-only corporate VPNs that don't like the ISPs NAT).

I mean, you are right. ISPs also need to stop complaining about supporting it and get off their butts. All enterprise routing equipment for the past 15+ years has supported IPv6. There is no excuse not to support it. Once you understand it, it is actually simpler than IPv4 + NAT.