ajie
ajie
@yvxiang ,你执行什么操作错core的
@lfrdreamman，非常感谢对tera的支持；请问你的运行环境是什么（Ubuntu，centos，或...）？跑onebox时core掉吗？执行什么样的teracli操作导致出core的？我这边希望根据你的反馈追一下问题。
split's bug: master scan meta before ts write meta it can be Reproducible
@syeerzy ，1）tera使用bfs和nexus，需要在tera.flag中设置如下标记： --tera_ins_enabled=true（使用nexus） --tera_zk_enabled=false（禁用zk） --tera_ins_root_path=/xxx/xxx （nexus上注册节点的路径前缀，不需要提前创建） --tera_ins_addr_list=ip:port,ip:port（nexus服务器地址列表） --tera_leveldb_env_type=dfs （配置使用分布式文件系统） --tera_leveldb_env_dfs_type=bfs （配置分布式文件系统类型为bfs） --tera_dfs_so_path=/xxx/xxx/bfs_wrapper.so （bfs的sdk的so文件位置） --tera_dfs_conf=/xxx/xxx/bfs.flag （bfs的sdk的配置文件） 2）linux服务器没有jvm也能启动tera
应该分裂失败，不应该core吧； 现有的逻辑是：在findsplitkey时，若按size分不开，则根据字符串距离分裂； 可以额外增加判断，计算这个逻辑距离产生的key切分出的tablet的size不能太小，若太小，则分裂失败，这样可以避免很多巨小的tablet。
这个我跟进一下，之前写了
what about HBase's snapshot? ref: http://www.slideshare.net/cloudera/internals-session-1 http://www.slideshare.net/jesse_yates/hbase-snapshots HBase relative issue: HBase 50
high level的做法是客户端缓存的目录树，将inode再转成路径，再转到对应的文件系统实现
1. rocksdb + ext4 + ssd，导致lsm引擎并没有很好的将底层硬件的能力发挥出来； 2. photon在rocksdb的协程化改造中，个人认为是做了一个非常好的尝试的，能否做到生产可用？如何可以的话，真是一个amazing的工作； 3. sdpk的blobfs比较精简，append only的特性，很好的和Rocksdb的io pattern适配；如果能结合photon的协程能力，个人感觉能给本地存储场景的rocksdb一个很好的工程实践
另外一写多读 情况下，读者在切主后 能否不通过reopen db 能升级成写者，解决计算层能热备的场景