Since v2.6.0 databases created on arm64 cannot be read from on amd64

[azy5030]

Since v2.6.0 a database created using an arm64 host cannot be read from on amd64. Say, for example, you create an lmdb on an M1 mac then ship that up to a kubernetes cluster operating in a mixed environment. The containers that start on amd64 hosts are unable to get values from the database, with calls to get() returning undefined.

I need to do more experiments to confirm if the reverse is true, and to rule out if this is an M1 specific issue. I also need to test if this is an issue specific to Node v18 (currently using 18.10.0). I will provide code for reproduction in the next couple hours.

[kriszyp]

Interesting. So far I have not been able to reproduce this. I've been testing by creating a database AWS EC2 ARM64 (Graviton2) and copying and opening it on an Intel (12700). One additional thing to note in terms of potential v2.6 changes that might be at play is that lmdb-js should now be defaulting to the system page size for the default database page size, which on MacOS on M1 is now 16KB, I believe. However, I did also test creating an database with { pageSize: 16384 } on my EC2 ARM64, but that seemed to work fine (to open on my local Intel computer with 4KB OS page size).

[azy5030]

Well that's just odd, as I'm able to reproduce it consistently. I'm wondering if virtualized vs. non virtualized hosts has something to do with it. I was generating the db by just invoking node directly on my mac, however it was unable to be read on the amd64 hosts both in github actions and in our eks cluster. Unsure about github actions how they do containerization, but in eks its obviously running inside a docker container.

I'll have more time to experiment this evening. Apologies for not getting the sample posted, as I was struggling with getting my intel mac to work last night and gave up out of frustration. I should have latitude to spin up arbitrary EC2 instances later though. I'll try and whittle down to minimum reproduction sets then.