Hi, @pcd1193182. I was inquiring about the inverse—whether including more
information in hash will cause hashing to diverge where it was previously equal
for similar values of \`os' or \`spa'.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
I believe this should read `safe for it _to_ return`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/commit/5d95a3a1d59b9c1f59faeef7886c82eaf831f956#commitcomment-24046149
Sounds more correct to say: `contained within each` as opposed to `contained by
each`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
andy-js approved this pull request.
LGTM.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/459#pullrequestreview-60271942
--
openzfs-developer
Hi @idodeclare, including the lower 8 bits of the spa and many more bits of the
os (because we're dropping the lower 8 and then & with 0xFF, so we only get
bits 8-15) does not decrease the quality of the hashing. It will not cause any
new collisions which did not already occur, and we perform a
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/461
-- Commit Summary --
* 8139 loader: efi multiboot2 update
* 8572 ccompile.h: rename __GNU_UNUSED to __unused
* 8558 lwp_create() returns EAGAIN on system with more than 80K ZFS
