Volker Lendecke wrote:
On Thu, May 22, 2014 at 01:33:10AM -0700, Howard Chu wrote:
Volker Lendecke wrote:
On Sun, May 18, 2014 at 03:51:38PM -0700, Howard Chu wrote:
Hmmm. I suppose it's a matter of timing. 64bit ARM chips are hitting the market now. Frankly I view this as a problem that will solve itself, and not worth lifting a finger over.
Just found via lwn.net:
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000335....
Interesting thread, but mostly it reiterates that no 32 bit systems will be viable past 2038. So there's a hard limit of 24 years remaining for these machines.
There may well be a plethora of 32 bit microcontrollers still running strong by then, but how many of them will be capable of managing more than 4GB of data? Do you really need a 16GB database in your smart toaster, smart refrigerator, or whatever networked appliance in the Internet of Things?
You never know. All I know is that Samba will need the 32-bit option for quite some time to come. If we started full steam lmdb, this meant that we need to maintain two database engines for the same purpose.
Only if you really expect 32 bit micro servers to manage more than 2-3GB of data. That doesn't seem realistic to me. Of course, I have only a vague feel for what the data is we're talking about. AFAICS this is filesystem metadata, which must be of much smaller volume than any actual file data being managed by Samba.
I'd like to avoid this if at all possible.
Fundamentally, this is unavoidable. Even if we cram the desired functionality into LMDB, it would end up being a different database engine, just hiding under the same name. The code paths would be completely different from the 64 bit code.