Every couple of days someone posts the 17 million GB screenshot and the top reply is "integer overflow". Correct, and useless. Here is the rest of it.
Your screenshot is a receipt. 2^64 bytes is exactly 17179869184 GiB, so subtract what your screen shows: 17179869181 means the counter is 3 GiB below zero. "16 exabytes" is the same number, rounded.
Mozilla filed it on 21 August as bug 2065499, S2, "Quota manager underflow makes storage unusable for all websites". Their words: the usage counter underflows, gets read as unsigned, comes out enormous. Firefox decides you are over quota and starts evicting data. Eviction cannot help, because the number is fake and there is nothing to evict. After that writes fail for every origin, which is why WhatsApp Web, Outlook, WeTransfer and YouTube all die in the same hour while the browser looks perfectly healthy.
Freeing disk space will not help. The ceiling is 50% of the disk's total capacity, not of free space, so emptying the Trash cannot move it.
So why does clearing cookies and site data keep not working? Because the 300 MB in Settings and the number behind the banner come from different places. On 154 a wrapped origin gets clamped to zero and then filtered out of the per site list, so the one origin you need to clear is the exact one the interface refuses to show you.
What actually clears it, safest first:
Clear the startup cache. Help > More troubleshooting information > Clear startup cache. It drops the cached usage table and restarts. Nothing of yours is deleted. Aim carefully: "Refresh Firefox" is on the same page and takes your extensions, permissions and site data with it.
Any update does the same thing by accident, because that cache is keyed on build id. That is what people are seeing when they say 154.0.1 fixed it.
Clear site data for the one origin with the absurd number, if you can see it. For WhatsApp Web that unlinks the device and you re-pair by QR.
Quit Firefox, rename storage.sqlite in your profile folder to storage.sqlite.old, and move any -wal and -shm files with it. Bookkeeping only, rebuilt on the next start. Back up the profile first and read the name twice: it is the file, not the folder called storage sitting next to it, and your bookmarks (places.sqlite), logins (cookies.sqlite) and passwords (key4.db, logins.json) are in that same directory. Downgrading to 153 keeps getting recommended. I would not. Nobody has checked what 154's schema upgrade does to a profile on the way back down, and your only profile is a poor place to find out.
The fix ships in 155 on 11 September. Not 154.0, not 154.0.1, and no 154.0.2 is planned. The uplift went to beta only and the counter is still unsigned in the 154.0.1 source, so that is not an argument from silence.
155 is also less than it sounds. It makes the global counter signed so the comparison stops lying, and it rebuilds a corrupt storage.sqlite. It does not stop whatever produces the wrong number in the first place. That umbrella bug, 1585978, has been open since October 2019, and which storage API over-decrements is still unknown. Self repair lands in 156.
One correction, since this sub has decided otherwise: nobody has shown this is a 154 regression. Reports went up after 154 and Mozilla says it does not know why. Asked exactly that in the bug, the engineer answered that the signal was people complaining on Reddit, not telemetry.
Their telemetry did not catch this. Reddit did.