跳至主要内容

博文

目前显示的是 2019的博文

望一眼

收档了. 纵然有深度 Google+ 用户不舍, 趁这最后几天在里面作别, 这时登上去, 还是可以通过各种无法加载出图标的按钮, 只剩下孤零零一条 post 的社群, 来侧面感受 Google+ 服务器那侧 Google 工程师的操作. 面对这种场景, 我仿佛能听到以前深夜路过商业街时, 店主们哧啦哧啦关上卷闸, 把展示柜拖回店里时跟地面的摩擦声. 又像是, 初中的每一次留校值日, 课桌椅摩擦地板发出刺耳响声, 空气中散发着稀释消毒剂蒸发起的气味, 无力的夕阳穿过窗玻璃折射在白墙壁. 世上也难有什么永恒之事, 只是 Google 热衷砍产品线, 才让用户感受到这种频频要跟喜欢用的产品道别的烦恼. 举一个可能已经为人熟知的例子, 典型且黑色幽默. Google 在聊天工具上的节奏, 从 Google Talk, 到 Hangout, 到 Allo, 到 Duo, 需求不断地提, 轮子不断地造, 运营一段时间, 哦, 貌似不太行, 关掉. 你甚至可以预期 Google 下次的 I/O 大会, 也会发布新的聊天工具, “我们又满足了一个 XX 的需求”, blabla. 只能说, 人生苦短, 我用 Telegram. 倒不是说’收档’给我带来如何大的影响, 实际上 Google+ 早在被宣布死亡日期前, 事实上也没有太多用到它的需求. 它在那时候的角色更像是一本用过的旧日记, 承载着很多或精彩或尴尬的回忆, 承载着各种事存在过的印记. 可以这么理解: 从 2013 年 Ingress 游戏开始存在, 到 2019 年 Google+ 宣布倒闭, 6 年间与 Ingress 相关的人事物, 那些值得发帖的, 发活动的, 都在 Google+ 上. 只是近两三年我, 或其他很多人们, 也都已经转向新平台. 显然商业公司不能容许这种白占资源不带来一丝盈利机会的情况发生, 可以说即使决策方换成不是 Google, 关闭的决定, 也几乎是必然. ‘旧日记’最好的状态, 就是让它保持现状, 可以让人需要时回来, 各个社群和圈子的人, 在事情发生的那段时间, 那些音容笑貌, 那些糗事笑料, 完整又立体地, 放在那里, 望一眼, 再望一眼. 是不是, 有点太恋旧了? ​

Syncthing 使用踩坑记录

硬盘缓存解决方案导致 Syncthing 数据库错乱 在某台式上用 Windows Syncthing (SyncTrayzor) 后一段时间后出现类似 这里提到 的 log. 可以看出关键的一句是: panic: leveldb/table: corruption on data-block (pos=0): checksum mismatch, want=0x222c5c3a got=0x6676beb6 [file=004278.ldb] 就是 Syncthing 用来存放同步内容哈希的数据库里某条记录跟实际文件的哈希对不上了。以这条 log 前半段 “panic: leveldb/table: corruption on data-block” 搜索一下可以看到前人的一些讨论. https://github.com/syncthing/syncthing/issues/2734 https://forum.syncthing.net/t/panic-leveldb-table-corruption-on-data-block/2526 https://forum.syncthing.net/t/panic-leveldb-table-possibly-due-to-ssd-caching/2673 我首先看到有人建议先清掉 Syncthing 的数据库文件夹再重启一下让它自动重新建数据库。于是 参考一下文档 找到 Windows 下的数据库文件夹位置。看到唯一那个 index 开头的文件夹,删掉。删掉这个不会丢失用户自定义的设置和同步文件夹设置. 重建 index 根据同步文件夹大小和电脑 CPU 耗时不定,200G & R5 2600 好像用了一个多小时. 重建之后随便加了一些文件测试同步,似乎没有问题. 两三天之后,问题重现. 根据上面查到的讨论开始怀疑是 AMD CPU 带的 StoreMI (用 SSD 给 HDD 加速的软硬件解决方案) 引起问题. 跟着 StoreMI 官方文档 开始把原本融合的两个盘拆开. 此处省略具体操作和电脑迁移数据时间 3 小时. 官方文档已经说得很详细了, 有不明白的, 请看多几遍文档. 之后再没发生类似问题. 由于文件同步的服务基本上都是用计算文件哈...