4 ms·

Besides epoch time and the LFS support mentioned, are there any other 32-bit bombs waiting for Linux systems like this?

by fred_is_fred 2y ago

fph 2y ago
IPv4, technically, is another 32-bit bomb, but that's not Linux-specific.
- samatman 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - poincaredisk 2y ago
    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.
    - icedchai 2y ago
      If more people bothered to configure IPv6 instead of complaining about it, V4 would be a thing of the past already.
      - o11c 2y ago
        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!
        account42 2y ago
        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).
        icedchai 2y ago
        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.
tredre3 2y ago
The ext file system uses many 32bit counters. Admittedly, version 4 fixed most of that (when formatted with the correct options).
- kbolino 2y ago
  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.
  - account42 2y ago
    ... 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.
  - lclarkmichalek 2y ago
    It does happen in prod. Usually due to virtual FSes that rely on get_next_ino: https://lkml.org/lkml/2020/7/13/1078 https://lkml.org/lkml/2020/7/13/1078
    - Dylan16807 2y ago
      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.
      - lclarkmichalek 2y ago
        There is a limit on reliable usage of the FS. Call it what you want. The user doesn't particularly care.

Besides epoch time and the LFS support mentioned, are there any other 32-bit bombs waiting for Linux systems like this?

fph 2y ago

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

samatman 2y ago
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.
- deleted 2y ago
  [deleted]
- poincaredisk 2y ago
  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.
  - icedchai 2y ago
    If more people bothered to configure IPv6 instead of complaining about it, V4 would be a thing of the past already.
    - o11c 2y ago
      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!
      - account42 2y ago
        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).
      - icedchai 2y ago
        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.

tredre3 2y ago

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

kbolino 2y ago
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.
- account42 2y ago
  ... 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.
- lclarkmichalek 2y ago
  It does happen in prod. Usually due to virtual FSes that rely on get_next_ino: https://lkml.org/lkml/2020/7/13/1078 https://lkml.org/lkml/2020/7/13/1078
  - Dylan16807 2y ago
    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.
    - lclarkmichalek 2y ago
      There is a limit on reliable usage of the FS. Call it what you want. The user doesn't particularly care.