群晖的DSM有一个比较鸡肋的功能：SSD Cache，原因如下：

1. 单条NVME只能做只读Cache，功能有限
2. 一个SSD Cache只能加速一个存储池（DSM 6.2中的词汇，以前叫存储空间）
3. 系统分区不在任何存储池里，所以系统分区上的东西都不能加速
4. NVME只能做Cache，不能用来存数据

DMS的SSD Cache功能是基于Linux的dm-cache来实现的，理论上通过Hack是可以解决上面说的这些问题的，不过得摸透了DSM相关的所有逻辑才能搞，而且对DSM的侵入比较大。所以，有一个想法，直接解决第4条问题，想办法把NVME当成正常的磁盘来存数据。然后就可以按自己的想法，灵活地挑一些需要高速随机IO的数据放在NVME上，其它的数据还是放在磁盘上。

如果问群晖的技术支持可不可以这样做，回答是否定的——非常可以理解，在群晖的设备上，盘位就是钱，白给你增加两个盘位？想都别想。

研究了一番，找到了解决这个问题的办法，虽然不完美，但是可用，并且效果不错。以下内容基于DS918+的硬件，DSM 6.2，系统中所有的磁盘都是Basic模式。由于条件所限，我没有测试RAID或SHR的情况，但原理应该都是一样的，可以参考一下我的思路。DSM的RAID就是标准的Linux RAID，而SHR则是基于LVM搞出来的。

以下步骤请充分理解后自行操作，所有给出的命令仅供参考，切勿依样画葫芦。这里介绍的方法有可能会造成不可逆的数据损失，请自己评估风险。

1. 分区

安装NVME后，系统中会出现/dev/nvme0n*设备，并且在存储管理器中可以看到对应设备。不要在DSM中创建SSD Cache，因为我们准备自己管理这个硬件。

Basic模式下，DSM会把系统中的每块硬盘都分成三个区：

Device      Start         End     Sectors Size Type
/dev/sdd1    2048     4982527     4980480 2.4G Linux RAID
/dev/sdd2 4982528     9176831     4194304   2G Linux RAID
/dev/sdd3 9437184 11720840351 11711403168 5.5T Linux RAID

第一个分区用于存放DSM系统，第二个分区是SWAP，第三个分区是用户可用的存储空间。每块磁盘的前两个分区，分别组成/dev/md0和/dev/md1两个RAID设备，都是RAID 1的模式。

所以，我们也依样画葫芦，把NVME也用相同的方式分区（可以使用系统自带的parted工具），分出与别的磁盘大小一样的前两个分区，类型都设置为RAID。然后剩余的空间分为普通Linux分区，并格式化为你需要的文件系统（ext4或btrfs）。当然，如果你有多块NVME或者你愿意，你也可以把剩余空间分为RAID类型，创建md设备后再格式化。

2. 创建RAID组

分完区后，扩展md0和md1，把NVME的前两个分区，加到这两个RAID组中。

# 如果是2盘位的设备，大概只需要扩展成3就可以了 
$ sudo mdadm --grow --raid-devices=5 /dev/md0 
$ sudo mdadm --grow --raid-devices=5 /dev/md1
$ sudo mdadm --manage /dev/md0 --add /dev/nvme0n1p1
$ sudo mdadm --manage /dev/md1 --add /dev/nvme0n1p2

然后，把第三个数据分区mount到一个你喜欢的位置，比如：

sudo mount /dev/nvme0n1p3 /volume1/homes/admin/nvme

考虑到NVME和磁盘混合组成RAID，可以把所有磁盘（不包括NVME）的对应分区设为writemostly，这样可以让读操作尽量走NVME，提高性能：

sudo echo writemostly | tee /sys/block/md0/md/dev-sdX1/state
sudo echo writemostly | tee /sys/block/md1/md/dev-sdX2/state

这样做完以后，系统分区和SWAP分区都已经可以被NVME加速了。这一步是完全没有风险的，因为即使未来NVME从RAID 1组中意外丢失或损坏，也不会造成任何数据问题。

同时在DSM中，正常访问home/nvme就是访问NVME上的内容，这个目录可以当作普通的存储空间来使用，存放一些需要高速随机IO的数据。

3. 迁移数据

为了达到更好的性能，我们还应该把一些常用的对IO性能敏感的东西迁移到NVME上，包括但不限于：

1. 系统的PostgreSQL/MariaDB数据库，通常位于/volume1/@database，但也可能分布在多块盘上
2. 软件包，通常位于/volume1/@appstore，但也可能分布在多块盘上
3. CloudSync的SQLite数据库，通常位于/volume1/@cloudsync
4. Docker的镜像和容量数据，通常位于/volume1/@docker
5. VMM的虚拟磁盘文件，通常位于/volume1/@Repository

迁移的方法很简单，先rsync，然后再mount –bind，比如：

sudo rsync -a /volume1/\@appstore/ /volume1/homes/admin/nvme/\@appstore/
sudo mount --bind /volume1/homes/admin/nvme/\@appstore /volume1/\@appstore

理想情况下，应该先把相关服务停止后（用synoservice命令可以启停服务）再迁移数据，避免迁移过程中有新数据写入造成不一致。为了保证万无一失，建议可以写个迁移脚本，在系统启动过程中所有服务还没有启动前运行一下这个脚本。

这一步是有风险的，因为万一未来某一次mount –bind没有成功或者没有做mount –bind，系统就无法访问到正确的数据了，这对于系统数据库之类的，还是有一定影响的，会造成数据不一致。

4. 重启自动生效

写一个脚本，用于在未来重启时重建RAID和mount相关目录，比如：

# 先把NVME上的数据盘mount起来
mount /dev/nvme0n1p3 /volume1/homes/admin/nvme
# 把SWAP的RAID 1扩容，并把NVME上的分区加进去
# 系统分区不需要，因为会自动完成。
# 但SWAP的RAID每次重启都会重建，所以每次都需要扩容。
mdadm --grow --raid-devices=5 /dev/md1
mdadm --manage /dev/md1 --add /dev/nvme0n1p2
# 把相关的目录mount --bind上去
mount --bind /volume4/homes/admin/nvme/\@appstore /volume4/\@appstore
mount --bind /volume4/homes/admin/nvme/\@cloudsync /volume4/\@cloudsync
mount --bind /volume4/homes/admin/nvme/\@database /volume4/\@database
mount --bind /volume4/homes/admin/nvme/\@docker /volume4/\@docker
mount --bind /volume4/homes/admin/nvme/\@Repository /volume4/\@Repository
# 重新设置RAID writemostly策略
echo writemostly > /sys/block/md0/md/dev-sda1/state
echo writemostly > /sys/block/md0/md/dev-sdb1/state
echo writemostly > /sys/block/md0/md/dev-sdc1/state
echo writemostly > /sys/block/md1/md/dev-sda2/state
echo writemostly > /sys/block/md1/md/dev-sdb2/state
echo writemostly > /sys/block/md1/md/dev-sdc2/state

修改/etc/rc，在SYNOINSTActionPostVolume这一行后面，增加一行对上述脚本的调用。SYNOINSTActionPostVolume执行完后，刚好是所有磁盘都mount好但是没有任何服务启动的时刻，所以这时做mount –bind是最合适的。如果你第三步数据迁移想在重启时做，也是加在这个位置。

这一步是比较不完美的，因为需要修改系统文件，而系统文件有可能会在更新DSM时被覆盖回去，万一被覆盖回去，系统启动后就是一个没有mount –bind的状态了，即使那时再改一遍脚本再重启，DB的一致性可能已经无法保证了。我暂时选用了一个带有一点防御性的做法（同样不是万无一失的）：在更新DSM前，把/usr/sbin/reboot改名，这样更新完DSM后系统不会被自动重启，我就可以有机会检查/etc/rc有没有覆盖，如果被覆盖，可以自己改回来以后再重启系统。

5. 其它经验和坑

• 数据迁移必须用mount –bind，不能用软链，已知有些应用组件在软链的情况下不能正常工作
• /volume1/@tmp不能迁移到NVME，即使用mount –bind，也会造成Drive等组件不能正常工作
• 现在的做法，NVME的第二个分区是后加到SWAP分区的RAID里的，所以每次重启都会有个重新同步的过程，IO会打高一会儿，并且完成后DSM会弹一个提示：一致性检查完成。但总体是可以忍的，所以我就没有去深究用什么方法可以在建立SWAP的RAID时就直接把它一起建进去了，因为我还是想尽可以少侵入DSM系统
• 用户的共享文件夹也可以通过mount –bind迁到NVME上，但是这样做会造成在共享文件夹管理界面上不能正常查看共享文件夹相关信息，所以建议只对共享文件夹里的目录进行mount –bind
• 如果你只有一条NVME，或者有两条但没有做RAID，那么迁移上去的那些系统文件都是单点（虽然原本在磁盘没有RAID的话是单点），需要留意其中的风险

2017年，我做了这些事：

– 网络生活

写了2篇博客，太懒了，除了开年的新年好和年末的新年音乐会两大作业文，2017年其它的内容居然什么都没写。其实有好几篇都在草稿箱里，只是都没有最终完成。博客空间总访问量31646 PageView（Google Analytics数据），数字下跌接近50％。跟前两年一样，依然是在吃老本，2010年和2013年写的几篇旧文章撑起了半边天。饭否发消息49条，其中包括照片16张。

给calibre修了两个微不足道的豆瓣元数据获取的Bug，给Seastar修了一个微不足道的Bug。

继续维持Linux Kernel Patch Statistics网站的运行，处理各种用户反馈过来的数据问题。几次想重构这个网站，方案也想了好几版，但是还是没有着手去做。最初的思路是想写个Flink的任务，流式去处理新的Patch信息，然后更新统计结果。后来仔细想了想，其实不用这么复杂，就目前的数据规模，直接把原始往数据库里一塞，然后正常查询就足够了。同时数据精准度也还有待进一步提高，但是这个主要是人肉工作，有不小的难度。期望2018年能把这个事情落地了。

– 几个IT产品

Amazon Echo Dot：对智能音箱的第一次尝试，总体感受是低于期望值。最重要的原因是它并不面对中国市场，所以很多功能并不适合在中国使用。最明显的就是在音乐播放这个功能上，无法识别中文歌名就是一个硬伤，播放自有音乐也非常困难。在智能家居方面，跟Home Assistant可以有一定程度上的集成，但是在国内依然用处不大。所以目前已几乎闲置。

天猫精灵：公测时第一批买到的，支持中文就是它最大的优点，智能家居的功能目前在国内也比Echo要稍稍接地气一点。从公测到现在有快半年时间了，能够看到它的明显进步的。目前在家里还是经常使用它的音乐、提醒、天气时间、智能家居等功能的。不过在有魔盒、魔盘等产品在先，我个人是不看好这类天猫XX的硬件产品的未来的。

SONY MDR-1000X蓝牙降噪耳机：在上下班的大巴上使用，降噪效果还是不错的，可以把音量保持在比较低的程度。不过这个产品有时会让我的耳朵产生胀痛的不适感。但是我其实一直没想明白，降噪的原理是把噪音声波的相位颠倒一下播放，那是不是就等同于一直有跟噪音音量相同的声音给灌到我耳朵里了？音量虽然开低了，但这个降噪的声音本身会不会损伤耳朵呢？

Brother PT-1230PC标签机：用几次就会吃灰的东西，所以买了个廉价的全新二手机器。接电脑使用是一件很不方便的事情，好处是可以完全自定义打印的内容。每次打印都会浪费很长一段标签纸，所以最好一批多打印几个才环保。然而它没有自动半切的功能，所以打印完以后还要手工把标签一段段的剪开（即使一次只打一个，也得手工剪掉前面浪费的那一段），这才是这个机器最不方便的地方。淘宝上的廉价耗材完全堪用，除了标签薄一点、表面光泽度稍差，在家用环境下应该都没有问题。

佳能CP910照片打印机：也是一个大部分时间吃灰的东西，所以也是买了个廉价的全新二手。现在偶而会有临时打印照片的需求，家附近的照相馆的打印的价格坑爹不说，主要是打印效果惨不忍睹，而线下或在线冲印服务则时效性不够。总体来说，对这个产品是满意的，打印的品质稍逊于冲印的品质，锐度和饱和度稍差。但是可以自己把屏幕调到跟打印出来的效果一致，这样就不用担心PS得好好的照片打出来不合心意了。

Synology DS918+：又换了个NAS，去年买的916+才用了一年多就把它换掉了。原因是新机器比旧机器便宜，买新卖旧，损失不大，而新机器可以支持NVME的SSD Cache，这样就不用浪费宝贵的硬盘槽位来做SSD Cache了。然而现实却并不美好，Synology的SSD Cache只能对一个存储空间生效，并且不会对系统文件分区进行加速，而且只用一条SSD时，只能进行只读Cache，所以除了在使用VMM时有那么一点点小作用以外，其它时候几乎都感受不到SSD带来的加速作用。

玩客云：迅雷出的“NAS”，背后的风起云涌的故事我就不讲了，反正我原价买了两个，卖了一个留了一个，就等于白拿了一个还有得赚。跟群晖比，这个东西真是连NAS都算不上，而且从安全性、可靠性等角度来说，我根本不敢用它。但是我非常喜欢它的思路，这才是普通人可以用的NAS：插上硬盘就能用，不用太担心内网、外网、端口映射的问题（群晖的QuickConnect？只能呵呵它一下了），没有文件、文件夹的概念，放进去的就是照片、视频、文档这样的数据，直接自动归类放好、视频文件自动下载元信息，需要的话可以手工再添加标签来分类。这样的产品用来做手机存储的扩展和备份，非常方便。

博朗耳温枪IRT6520：2016年买了一个，2017年又买了一个，必须专门拿出来黑它一下。山寨做工就不说了，操作繁琐也不说了，重点是太太太容易坏了，而且几乎没有质保。2016年我是亚马逊闪购买的，无质保。2017在京东超市自营买的，坏了依然需要自己跟代理商扯皮。一气之下直接联系了京东客服投诉，京东售后自己给兜底了，换了个新的。现在每次用还是提心吊胆的，不知道什么时候就又会测温不准了。

荣耀V9手机：三年内买的第6个荣耀手机，现在半家人都在用荣耀手机。华为的产品不良心，但还算省心。荣耀虽然硬件各种缩水，但是日常用用还算够。V9的屏幕色彩调得有点夸张，乍一看还挺惊艳的，但是仔细看还是掩盖不了它的低端屏幕的本质。NFC当公交卡很好用，指纹解锁我也一直觉得国产手机全都可以秒杀同时期的iPhone。

戴森V8 absolute吸尘器：跟只有它价格十分之一不到的某型号的小狗吸尘器来比较，它工作时的表现确实是非常不错的。不过它的塑料件的质感和做工，真是对不起它的价格。另外，因为所有的主要部件（电机、电池）的重量都在手上，所以使用起来还是有点费劲的，尤其是使用短小的吸头清理小地方的时候。

– 出行

量子号邮轮，出行前只要多看看网站评价中的差评，就可以把自己的心理预期降低到一个合理的程度，然后就可以玩得很开心。邮轮旅行的陆地行程大都是坑爹的，正确的姿势就是充分享受在船上的休闲时光。

成都，对于不能吃辣又本来就不是吃货的我，成都算不上是一个“来了就不想走”的城市。大熊猫基地比想象的要有意思一些。

南京/江苏大剧院，江苏省终于有了一个说得过去的音乐厅。祖宾‧梅塔和以色列爱乐的演出，虽然比不上维也纳爱乐乐团，但也足够惊艳。期待2018年能有值得让我再专门跑一趟的演出。

千岛湖，一个除了休闲啥也干不了的地方。

展望2018年：

还是说点工作，2017年在工作上实现了从Java回到C++的转型，如果说C++ 14语言和纯异步编程带来的挑战还不是个大问题的话，真正的挑战存在于从简单业务代码开发转型为去做高性能底层系统的设计和实现。尤其是设计阶段需要参考很多现有的系统和论文，去理解它们的设计意图，去理解它们的实现机制，并在这个基础上找到适合自己的方案，在之前没有太多积累的前提下，非常难。

可以说，2017年的工作压力是相当的大，也是我自己第一次在工作中真正开始怀疑自己分析、解决问题的能力。不过在经历了系统的几次迭代后，似乎还是找到了一点点感觉，期待2018能更好的迎接新的挑战。

2016年，我做了这些事：

– 写了8篇博客

博客空间总访问量61198 PageView（Google Analytics数据），比前一年稍有下降，但是实际的访问量应该还没有这么多，因为发现Google Analytics结果中出现了相当数量的Spam数据，暂时还没研究怎么能去过滤掉。跟去年一样，首页、在Linux下使用“360随身WiFi 2”、calibre常见问题、为Raspberry Pi 2编译内核模块这几个页面的PV占去了总PV的50%多。饭否发消息85条，包括照片17张。

– 自由软件相关

接手了一个网站：Linux Kernel Patch Statistics。这个网站的内容是按人、公司、国家等维度的指标去统计各Linux内核版本中Patch的数量。我很偶然地看到有人在LKML中吐槽说这个网站的域名过期了。这个网站的作者是我以前的同事，于是我联系他提醒他，没想到他表示说不打算继续维护这个网站了。我觉得就这么放弃一个在社区有一定影响力的网站有点可惜，所以在征得他同意的前提下，把这个网站接了过来，并且还请朋友帮忙把过期的域名给抢注了回来。

网站恢复运行的不到一个月时间中，我已经收到各种数据订正、添加功能和Bug报告的邮件，看来这个网站的的价值比我想象的还大一些。不过这个网站的后台代码确实是经久失修，所以目前数据统计的精准度非常糟糕（因为根据邮件地址把数据按公司、国别来归类，这里面的映射关系绝大部分是需要人肉来维护的，一旦没有及时维护，归类为Unknown的数据就会越来越多，也就失去了统计的意义），而且每天一次全量数据产出过程需要占用大量的CPU、IO和内存资源。所以后面需要优先先维护一下基础数据，保证统计数据质量，然后再考虑下整体的重构问题。

给calibre贡献了一点点代码，改写了一下从Amazon获取书籍元信息的插件，使之可以支持中国亚马逊网站。给HBase和Flink的代码/文档各修正了一处Typo，其实只是为了实践一下给这两个项目Contribute的流程，不过后来由于工作内容的变化，没有再深入关注过这两个项目。给C++异步框架Seastar修正了一处Bug。train-graph合并了一些其它人贡献的代码和数据，发布了一个3.0版本。

– 几个IT产品

群晖DS916+ NAS：淘汰了原来用的DS214play，主要是出于盘位和性能的考虑。不过新的机器的性能依然很让人捉鸡。不过出于对DSM系统版权的尊重，我还是没有选择自己买机器组黑群晖的方案。我的群晖系统的评价依然是：轻度使用很不错，重度使用时细节缺失很多、问题也很多。但是市面上已经找不出更好的了。

Macbook Air：公司提供的工作电脑，我的第二台苹果设备（N年前得到过一个iPod Nano）。这样的电脑用来做开发机实在是性能捉鸡，尤其是为了编译Linux程序再启一个Docker的情况下。公认的优点就不说了，缺点就是有些Windows能做的事情它还是不能做，而有些Linux能做的事情它也不能做。对于我这种已经被Linux虐了十年的人来说，不能做Windows能做的事是很容易接受的，但现在不能做的事的又变多了，所以还有点不爽，于是有了下面的Dell 7040m。

Dell 7040m微型台式机：为了更有效的开发Linux C++程序，买了这个微型台式机当工作机。配置成i7 6700T的CPU，16G内存，SM951的SSD，装Arch Linux。实际用下来整体能满意，但是就编译大型C++程序来说，单核性能仍然不是非常出色。另有同事买了相似配置的Intel的Skull Canoyo，也是差不多的体验。我也知道我的应用场景下应该买个标准台式机才能配置更好性能的CPU，但是谁让我这个机器的外型的毒呢？

华硕AC68U路由器：其实去年买的AC66U完全够用了，不过还是因为一次特价剁手了更高端一点的AC68U。整体使用体验与AC66U相仿。不过从外观来说，我反而还更喜欢AC66U一点，AC66U给人的感觉是做工精致、用料实足。AC68U其实也一样，但给我的感觉却是：傻大笨粗。

Raspberry Pi 3：没啥说的，我是树莓派的脑残粉，出一个买一个。相对2来说，主要就是64位、内置蓝牙和Wi-Fi，性能稍有提高，别的就没有了。树莓派是吃灰神器是名不虚传的，这个现在已经吃灰。还买了一个Sense HAT传感器模块，做了一个贪吃蛇游戏后也吃灰了。有了3以后，我用以前吃灰的2和Camera Module做了一个网络摄像头，配合群晖做监控，效果勉强凑合。

Pebble 2：本来是在Kickstarter预定了Pebble Time 2，但因为正在用的Pebble花屏越来越严重，等不及就先收了一个Pebble 2，没想到次日Pebble就宣布被fitbit收购了（我觉得与其说是收购，不如就当是破产了更合适），Time 2也没有机会再问世了。Pebble 2的使用体验与Pebble高度一致，我很满意，只可惜这已经是绝唱了。希望在它坏掉以前，能有更出色的产品出现。

二手Kindle Paperwhite 2：跟以前用的Paperwhite比，差别并不大，只不过因为Paperwhite被老妈重度使用中，所以自己重买一个。没买3是因为性价比，毕竟我也不是重度使用。而且看书这个单一需求来说，我并不觉得Paperwhite 1/2/3/Kindle Voyage有多大的差别。

二手Intel Compute Stick：我需要一台常开的Windows机器来满足把NAS上的照片上传到 Google Photos的需求，这个东西很符合我的要求，功耗不到5W，直接由路由器USB口供电就可以了。性能对于我来说也完全够用，有了它不但解决了Google Photos上传的问题，甚至我的电脑上已经不再需要安装Windows虚拟机了，偶而需要用Windows的时候，直接远程桌面连上去用就可以了。

– 出行

南京*3、合肥、西安。对南京的感情依然不变、合肥真不是一个旅游城市、第二次去陕西省历史博物馆已找不回第一次去时惊艳的感觉。

展望2017年：

谈点工作，在用Java写了4年业务代码后，2016年，我终于又回归了技术开发。在短暂地用了一段时间Scala后，还回归到了C++开发。说是“回归”，其实还是更大的挑战，因为需要用C++ 14来写一些高性能的分布式程序，对于我来说也仍然是一个全新的课题。期待2017年可以在这个方面能有所收获。