dets在64位系统还是有可耻的2G限制

原本以为在 64位操作系统下 文件的读写指针都改成64位的 避免了2G的限制。经过测试 disk_log和file都支持超过2G的数据文件，但是 dets还是可耻的失败了。 经过查看源码 有2个问题：

1.  key segment的问题。  dets在设计的时候 是针对32位的 那么它的空间限制就是2G， 所以在计算最大的段的数的最大的偏移时候 干脆在代码里面写死了2G。


2. 偏移的问题。 每个key对应的value在dets_v9文件格式中的偏移值是用 <<Off:32>> 这样的格式来表示的。 所以如果改变成64位 那么文件格式就完全不兼容了。


结论： dets支持2G以上没戏了， 而且同样影响到mnesia.

too bad, mnesiaex也不能完全替代mnesia吧

mnesiaex是用tc来代替 dets做永久存储。

mnesia也有问题？？？？

mnesia的存储用的是ets和dets 当然有问题了。看到邮件列表的人在讨论这个问题。 有人提议说 干脆用tt来做底层存储。 我也赞同。

真是比较期待，他们打算怎么做呢？
mnesiaex只是一个实验产品吧，而且更新也不频繁，不过mnesia本身最近几个版本的修改也不频繁。

找到这个讨论的地址了：http://www.erlang.org/cgi-bin/ezmlm-cgi?4:sss:47828:200911:aielfgbhpmkpdcoonbcl#b

讨论很有含金量，
- Tokyo Cabinet has slightly different recovery
   characteristics than dets. This may make a
   difference in some crash recovery situations.
   That is, TC gets its speed partly from making
   use of memory-mapped IO, so more data is likely
   to get lost in some failure situations. TC is
   supposedly also more sensitive to corrupted files
   than dets, since it doesn't 'repair' the file
   like dets does.

里面还提到disc_copies可以突破2GB的限制（不过被内存的大小限制，其实也好不了多少）

谁说可以突破2G 人家说的是fragment, dets文件写死了是32位的offset.

tc可以超过2G in 64 bit..

我的vector data曾经单文件 超过5G..不过性能很差就是了

tc当然可以 设计的时候就是考虑64位的