# [PATCH] opcache bug #69090, prepend user identifier to keys

- Thread: https://externals.io/message/96935
- Original archive: https://news-web.php.net/php.internals/96935
- Started by Dmitry Stogov on 2016-11-16T20:56:45+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #96935 — Dmitry Stogov — 2016-11-16T20:56:45+00:00

URL: https://externals.io/message/96935#96935

>
> 
> > […]
>
> To clarify: My concern is not with the way the hash is compared, but that the root hash itself could have collisions. That is, you have two root inodes I1 and I2 and two root hashes R1 = H(I1), R2 = H(I2). In that case it may be that R1 == R2, but I1 != I2. At least that's the way I understood the patch -- it doesn't looks like there is anything explicitly preventing this.

I see. Actually, for 64-bit systems it's better to eliminate bits permutation at all, but for 32-bit we can't avoid possible collisions, even if we include high bits into hash.

The good thing, that inodes above 2^32 may make sense only on filesystems above 16TB with 4096 block sise (may be I'm wrong).

do you have any ideas?

Thanks. Dmitry.

>
> Nikita

---

## #96937 — Dmitry Stogov — 2016-11-16T21:09:18+00:00

URL: https://externals.io/message/96935#96937 · In reply to: #96935

https://www.quora.com/What-is-the-maximum-number-of-inodes-in-Linux-filesystems-I-found-suggestion-that-for-Ext4-it-is-4-billion-files-32-bit-number-Is-it-true-for-XFS-and-or-BtrFS