2020新年好

2019年,我做了这些事

– 网络生活

博客疏于打理,只剩下交作业的两篇了。有比没有好,至少说明这个博客及其主人还活着。博客总访问量持续下跌,为16230 PageView。饭否消息24条,其中照片8张。

由于豆瓣网关闭了API(也可能只是封禁了我的API Key,但是联系豆瓣无果),calibre中的豆瓣元信息插件就不能工作了。目前来看,改成直接爬网页的方式可能会比较靠谱。虽然用户的呼声很高,然而我个人最近没有时间投入开发,只能眼睁睁地看着它不能用了。如果有哪位朋友有兴趣,可以尝试开发一下,应该并不困难。

– 一小堆数码产品

三个华为Mate 20 6+128:爸爸、妈妈和我自己都用上了。各项指标都很均衡的水桶机,电池给力、相机够用,在5G真正发挥威力前过渡一下还是合格的。年末时的价格只有年初时的不到1/2,可谓是真香机了。没有买Mate 20 Pro/P30系列/Mate 30系列的原因是“LCD永不为奴”。中间还尝试买过一个Mate 20X(4G版),试用了一天就出了,屏幕不能忍,而且太笨重了。另外还买了荣耀V20和荣耀8X,帮其他家人买的,没有体验心得。

Retroflag GPI Case树莓派掌机:外壳背后的核心是一块Raspberry Pi Zero W。到手后大概总共就玩了三天的GameBoy Color版的塞尔达传说之织梦岛——怀念了一下这个刚上大学时玩过的这个游戏,然后就吃灰了。原因很简单,没时间玩。

一个山寨的无线小键盘,似乎没有什么名牌的产品有对标的产品。用于偶尔调试树莓派、路由器或机顶盒,很便宜但异常好用。另外手机上接个USB Type-C转Type-A的适配器后也能在手机上用,有时出门不带电脑也能更方便地用手机SSH处理一些紧急的问题了。另外还买了一个山寨的HDMI触摸屏,也是用来接嵌入式设备偶尔用用的。

大疆OSMO Mobile灵眸手机云台3,冲动消费,目测也有吃灰的潜质。不过在有使用场景的情况下,确实还是挺好用的。有了稳定器并不能天然就拍出更好看的视频,需要一段时间的练习和适应,不然乱晃的话,拍出来的视频会让人看上去更头晕。

口袋阅电子书,冲着免费拿去的,当然后果就不出意外地没有完成打卡任务被反薅了。产品其实凑合还能用,看文字类的电子书还是可以的,只不过性价比太低了。

BOSCH GO电动螺丝刀,真难用,到手解毒。这类工具多半还是传统的好用,随意地创新就是个坑。因为是京东夺宝岛搞来的,价格不高,所以第二天就加了几块钱闲鱼出掉了。

– 旅游

千岛湖酒店躺尸两次,千岛湖真是个没啥好玩的地址。其中有一次还去坐了船上岛,我已经把坐船上岛这件事想得足够无聊了,但没想到岛上比我想象的更不好玩。

安吉江南天池滑雪,山上酒店很破。滑雪还是需要有会的人指导一下,然后就是必须上雪坡体验。在平地上练习不会有什么成效,而且会非常无聊。

上海东方艺术中心一晚游,去聆听了穆蒂与芝加哥爱乐乐团的演出。演出精彩,不虚此行。

– 其它

我的第一本O’reilly动物封面书译作最终还是没有出来,一方面是因为交稿晚了一些,另一方面是为了给《基于Apache Flink的流处理》一书让路。Flink这本书我三年前就跟编辑敲定了版权,但因为原著拖拉到了2019年才出版,加上我自己的工作内容发生了变化,所以把这本书由Flink China社区转交给Flink Committer 崔星灿翻译了。为了赶上11月底召开的Flink Forward Asia 2019大会,译者和出版社都付出了极大的努力,可惜最终还是晚了两周。但是能在这么短的时间内出版了质量如此之高的热门技术书,已经是非常不容易了。

发现O’reilly开始推新版的彩色动物封面书,加上自己正在好学习Kubernetes开发,于是又手痒开始翻译另一本Kubernetes编程方面的书,就当是边译边学了。目前进度有点Delay,但是翻译工作已经完成,正在审阅阶段,期望2020年内能顺利出版。

关注2020维也纳新年音乐会

曾经关注过的那些维也纳新年音乐会:关注维也纳新年音乐会

这篇文章半个月前写了个开头,一直没发出来,因为感觉没有太多想说的,但又不想放弃传统,颇为纠结。昨天,突然听到指挥大师杨松斯去世的消息,有点伤感。2006年杨松斯第一次指挥新年音乐会的演出就给我留下了深刻的印象,我喜欢他热情奔放的指挥风格和洋溢着节日气氛的笑脸。人生无常,不能拖拉,赶紧加班加点把文章写完了。

2020年维也纳新年音乐会的指挥台上又将迎来一位新的指挥家——拉脱维亚指挥家安德里斯·尼尔松斯。尼尔松斯是杨松斯的学生,人称“胖葱”。2017年10月,尼尔松斯曾携维也纳爱乐乐团在江苏大剧院演出过贝八和《英雄的生涯》,可惜当时一念之差没能去现场聆听,心存遗憾。

2020年维也纳新年音乐会CD封面

SONY录音的这几年的CD封面毫无看点,之前三年还引入了一些圆形、弧形的元素,今年则又是回到以前方方正正的风格。

  • 01 – Carl Michael Ziehrer – Ouvertüre zu “Die Landstreicher – 轻歌剧“流浪汉”序曲 *
  • 02 – Josef Strauss – Liebesgrüße. Walzer; op. 56 – 爱的问候圆舞曲 *
  • 03 – Josef Strauss – Liechtenstein-Marsch; op. 36 – 列支敦士登进行曲 *
  • 04 – Johann Strauss II – Blumenfest-Polka; op. 111 – 花节波尔卡
  • 05 – Johann Strauss II – Wo die Citronen blüh’n; Walzer; op. 364 – 柠檬花开的地方圆舞曲
  • 06 – Eduard Strauss – Knall und Fall. Polka schnell; op. 132 – 轰然倒下快速波尔卡 *
  • 07 – Franz von Suppé – Ouvertüre zu “Leichte Kavallerie“ – 轻骑兵序曲
  • 08 – Josef Strauss – Cupido; Polka française; op. 81 – 丘比特法兰西波尔卡 *
  • 09 – Johann Strauss II – Seid umschlungen, Millionen; Walzer; op. 443 – 百万次的拥抱圆舞曲
  • 10 – Eduard Strauss – Eisblume; Polka mazur; op. 55 (Arr. W. Dörner) – 冰霜之花玛祖卡波尔卡 *
  • 11 – Josef Hellmesberger jur. – Gavotte – 加沃特舞曲 *
  • 12 – Hans Christian Lumbye – Postillon-Galopp; op. 16/2 (Arr. W. Dörner) – 驿站车夫加洛普 *
  • 13 – Ludwig van Beethoven – Zwölf Contretänze; WoO 14 (Auswahl) – 十二首乡村舞曲之第1、2、3、7、10、8号 *
  • 14 – Johann Strauss II – Freuet euch des Lebens; Walzer; op.340 – 享受生活圆舞曲
  • 15 – Johann Strauss II – Tritsch-Tratsch; Polka schnell; op. 214 – 闲聊波尔卡
  • 16 – Josef Strauss – Dynamiden. Walzer; op. 173 – 神秘引力圆舞曲
  • 17 – ?
  • 18 – Johann Strauss II – An der schönen blauen Donau, Walzer, op. 314 – 蓝色多瑙河圆舞曲
  • 19 – Johann Strauss I – Radetzky-Marsch, op. 228 – 拉德茨基进行曲

2020年维也纳新年音乐会的曲目单中包含了16首正式演出的曲目,其中有9首是第一次出现在维也纳新年音乐会中的新曲目。尤其值得一提的是,2020年是贝多芬诞辰250周年,所以在下半场特别选择了贝多芬的一些舞曲作品,这是贝多芬的作品首次出现在维也纳新年音乐会的舞台上。

16个曲目中小约翰的作品占了5个,不但都是以前演奏过的曲子,更惊人的是,其中4个曲目与1988年阿巴多指挥的新年音乐会的选择如出一辙,剩下一个《花节波尔卡》则曾经在1996年马泽尔指挥的新年音乐会上出现过。

新曲子主要是约瑟夫和爱德华作品。爱德华为施特劳斯家族中最小的一员,他的作品在新年音乐会上亮相的机会并不是非常多,这些曲子应该是这次音乐会的亮点之一。

除了施氏家族和先前提到的贝多芬,这次音乐会上还将出现苏佩、齐雷尔、赫尔梅斯伯格和伦拜的作品,这几位作曲家也是新年音乐会爱好者的老朋友了。尤其是苏佩的轻骑兵序曲,更是一首耳熟能详的曲目,我很喜欢这首充满着朝气曲子。

新年音乐会要来了,也就快到了要跟这一年说再见的时候了。今年总共听了两场音乐会现场,一场是年初在上海东方艺术中心的穆蒂与芝加哥爱乐乐团的演出,另一场是在杭州大剧院雅尼克·涅杰-瑟贡与费城交响乐团的演出。与新年音乐会相比,这两场演出相对来说要严肃的多。综合考虑乐团、曲目、场地、观众等因素,总体感受前一场要更胜一筹。好的演出真不需要太多,期待明年还能有机会现场聆听高水平的音乐会。

2019新年好

2018年,我做了这些事

– 网络生活

写了3篇博客,除了按惯例交作业的两篇,就写了一篇折腾群晖NAS的经验分享文章,而且这篇文章我现在来看觉得又过时了,过几天得重写一篇,因为我找到更好的办法来解决相同的问题了。博客总访问量持续下跌,为25475 PageView,自作孽不可活。饭否消息21条,其中照片8张。

开源与自由软件方面,因为工作需要给gdbgui项目贡献了一个微不足道的功能。

年初立的Flag要给Linux Kernel Patch Statistics改版的计划,最终还是没有实现。要不继续当成2019的计划?

也许可以总结为在生活上投入的时间越多,在网络上投入的时间就越少?

买了一个fanxi.li的域名,虽然我一直觉得用名字拼音当域名不是很make sense。不过由于现在.li域名无法在国内备案,所以我也没(打算/办法)把它当主域名来用,只是用它来做跳转域名,比现有的域名简洁一点,可以少敲几个字符。

– 一堆IT产品

斐讯K3路由器:没下车就翻车的斐讯产品。K3性能强劲,但是散热硅胶有漏油的毛病,被誉为“漏油器”。主要是第三方固件不是太给力,官改固件因为内核原因也不完美。最终闲置了。

斐讯K2P路由器:0元购成功下车。不考虑0元购情况下,直接买已下车的版本,曾经最低价不到百元,是200元以下路由器中的无敌手。刷成“荒野无灯”版的固件后(暂不讨论第三方固件的安全性问题),使用稳定。非常满意。

斐讯悟空空气检测器:直接买的下车版本,做工不错,检测结果准确性嘛,PM2.5说得过去,HCHO的话,一句话,电化学传感器的都不准。好处是它已经被研究得比较透彻了,直接接入HomeAssistant很方便。

斐讯T1电视盒子:0元购成功下车。不看价格的话,斐讯一系列的产品的硬件确实都是堆料之作,做工扎实,配置也不错。不过家里盒子太多了, 这个最后还是闲置了。似乎现在有很多人拿它玩出了花,不过我没太关注。

天猫路由:内测产品。2018年出个百兆有线的无线路由器,说再多也没意义了。虽然硬件配置还不错,无线信号与实测速度也不错。但是初版固件功能极弱,除了可以上网,其它功能一概没有。对,端口映射都没有。

天猫精灵魔盒:内测产品。就是把天猫魔盒与天猫精灵融合在一起的一个产品。刚开始的使用体验惨不忍睹,正式上市的版本勉强能用。但是为了在电视开关机两种情况下提供不同的功能而引入的两种工作模式,依然让使用体验变得很诡异。最主要的重点在于,语音控制对于一个电视盒子来说,比用遥控器能带来哪些使用体验上的提升?几乎大部分场景下、遥控器都比语音控制要方便、快捷,我能找到的唯一一个点是:搜索指定内容。

华米手表青春版:Pebble 2不到两年就光荣牺牲了,跟很多人一样,双侧的橡胶按键因为老化,直接破损了。Pebble被Fitbit收购,已经又一次证明,被Geek看好的产品,通常都不是好产品。华米手表除了部分细节功能不如Pebble(比如免打扰模式无法设置只进行来电提醒、无法定制不同类型提醒的振动模式),以及表盘定制能力不及Pebble,其它功能都很让人满意,工作稳定可靠,不像Pebble还时不时蓝牙连接默默断开给你脸色看。没有选择小黑3是因为它的外观,没有选择别的智能手表大都是因为续航。

OLPC XO-1:十年前非常想要但不太买得到的OLPC,也就是当年所谓的“一百美元笔记本”,如果不了解的,可以搜一下相关的历史。在闲鱼上淘到了一个洋垃圾,毫不犹豫的下单了。放到今天,这东西可是真垃圾,但是它的一些设计即使到今天来看,也还是非常独特的,比如那个双模的显示器。玩了几个小时,不出意外的闲置了,纯当收藏了。

Dell 7060 Micro:前年买的Dell 7040 Micro台式机还是挺满意的,今年Intel牙膏挤多了,8代CPU提升很大,所以换成了Dell 7060 Micro,配上了顶配的8代i7标压CPU。尽量Dell给这个系列使用i7标压U的机器单独配备了专用的散热组件和大功率的电源,这种小机箱的散热还是不太够,i7无法满载运行。内存我已经加到了32G,但是还是没法满足工作中编译代码的需要(单CPP文件编译可能会耗费4G或更多的内存,开6个并发就废了),所以现在用着高配置的机器却只跑了个Terminal和IDE,编译这种费力的工作还是扔到远程服务器上去做了。

MikroTik RB750Gr3 + Arbua AP-205H:这个路由+AP的组合,是买来尝试软路由方案的,两个月后又闲鱼上卖掉了。RouterOS的设计和操作对于家用路由器来说有点反人类,而Arbua这种专业AP也会让初次使用者觉得摸不着手脑。在经历了尝试用群晖虚拟机跑OpenWrt、MikroTik+Arbua等几个家庭网络方案后,我回到了原来的AC68U硬路由的方案。我的结论是,在带宽和带机量都不足够大的家用情况下,除非在路由器上需要部署大量加解密、协议分析(比如去广告)这种重CPU的功能,否则X86软路由无论从性能还是功耗上,性价比都远低于同档次的硬路由。

EPSON L4168打印机:低端墨仓式一体机的网络爆款。从功能上来说,连供、彩色打印、复印、扫描、无线、自动双页,完全对得起1300多块的价格。但是我在十五年前花330块买过一个HP 3538打印机,从文本打印品质来说,可以秒杀这个新的L4168,所以新机器刚到手的时候还是颇为失望的。现在用了一段时间习惯了,也就不纠结了。

暴风酷播云:曾经5000多块的矿机,在矿难后有商家在闲鱼上抛售,价格从500多一路暴涨到现在的近800,估计不久又得崩盘。万由的双盘位机箱,华擎的J3455主板,单条金士顿DDR3L 8G内存,自带16G SSD可以当系统盘,满载功耗40W左右。相当于群晖DS918+的配置,用来做家庭小服务器/NAS/软路由还是很不错的。学习了Proxmox这个可以代替VMware ESXi的虚拟化管理系统,很不错,够用。

– 出行

海口/三亚四日:除了住酒店还是住酒店,除了游泳还是游泳,除了沙滩还是沙滩。有人说这就是正确的度假姿势。这次行程从浦发银行信用卡上撸了不少羊毛。

厦门三日:除了住酒店还是住酒店。这真不是我风格,我已经是老年人了吧?

苏州两日:走马观花跑景点,有点累。

– 其它

正在着手翻译一本Drill的书,预计2019年上半年可以出版,可能会是国内同体裁的第一本。原因无它,就因为我想出一本O’Reilly的动物封面的书。

我是一名坚持了十几年的Linux桌面资深用户,2018年年底,发现Windows 10自带的Windows System for Linux已经基本堪用,义无反顾地倒戈回了Windows。虽然Windows 10跟以前版本的Windows比,又丑Bug又多,但总体来说桌面体验还是比Linux强多了。macOS?我用了四年多,但似乎我的脑回路还是与它有点不兼容,我不太喜欢macOS所提供的交互逻辑。

展望2019年:

最近有句话很流行:“2018年是过去十年里最差的一年,却是未来十年最好的一年。”我并不觉得这句话很消极,每个人都应该有点忧患意识,有点抵抗风险的准备和能力(此处可以乱入卖保险的广告)。避免功利地去评估一件事情是否值得去做,尝试更踏实地做好一件件小事。不能期待一蹴而就,薄发来自于平时点点滴滴的厚积。

关注2019维也纳新年音乐会

曾经关注过的那些维也纳新年音乐会:关注维也纳新年音乐会

一年又快要过去了,又快要到了迎接新年、迎接维也纳新年音乐会的时候。

2019年维也纳新年音乐会将由德国指挥家克里斯蒂安·蒂勒曼执棒,这是绰号“大熊”的他首次执棒新年音乐会。他是新年音乐会迎来的第17位指挥家,也是继克莱伯之后的第二位德国指挥家。

CD封面还没出,暂时只能配个指挥的图了:

斯蒂安·蒂勒曼

斯蒂安·蒂勒曼

上半场

01 – Carl Michael Ziehrer – Schönfeld-Marsch; op. 422 – ·勋菲尔德男爵进行曲 *

02 – Josef Strauss – Transactionen; Walzer; op. 184 – 交易圆舞曲 – 1981, 1993

03 – Joseph Hellmesberger jun. – Elfenreigen – 小精灵的舞蹈 – 2007

04 – Johann Strauss II – Express; Polka schnell; op. 311 – 特快列车快速波尔卡 *

05 – Johann Strauss II – Nordseebilder; Walzer; op. 390 – 北海风光圆舞曲 – 1998, 2005

06 – Eduard Strauss – Mit Extrapost; Polka schnell; op. 259 – 特快邮车快速波尔卡 – 2000, 2016

下半场

07 – Johann Strauss II – Der Zigeunerbaron; Overtüre – 吉普赛男爵序曲 – 1987, 1992, 2009

08 – Josef Strauss – Die Tänzerin; Polka francaise; op. 227 – 舞女法兰西波尔卡 *

09 – Johann Strauss II – Künstlerleben; Walzer; op. 316 – 艺术家的生活圆舞曲 – 1989, 1999,  2002, 2006

10 – Johann Strauss II – Die Bajadere; Polka schnell; op. 351 – 印度舞伎快速波尔卡 – 1997, 2005, 2008

11 – Eduard Strauss – Opern-Soiree;  Polka francaise; op. 162 – 歌剧院晚会法兰西波尔卡 *

12-13 – Johann Strauss II – “Ritter Pásmán”, Evas Walzer und Csárdás – 伊娃圆舞曲 * & 查尔达什舞曲(选自轻歌剧《骑士帕斯曼》) – 1967, 1989, 2000, 2011

14 – Johann Strauss II – Ägyptischer Marsch; op. 335 – 埃及进行曲 – 1993, 2014

15 – Joseph Hellmesberger jun. – Entr’acte Valse – 幕间圆舞曲 *

16 – Johann Strauss II – Lob der Frauen; Polka Mazur; op. 315 – 赞美女人玛祖卡波尔卡 – 2003, 2006

17Josef Strauss – Sphärenklänge; Walzer; op. 235 – 天体乐声圆舞曲 – 1954, 1964, 1979, 1980, 1983, 1987, 1992, 2004, 2009, 2013

18 – Johann Strauss II – Im Sturmschritt; Polka schnell; op. 348 – 飞奔快速波尔卡 – 1990, 2004, 2016

加演

19 – – ?

20 – Johann Strauss II – An der schönen blauen Donau, Walzer, op. 314 – 蓝色多瑙河圆舞曲

21 – Johann Strauss I – Radetzky-Marsch, op. 228 – 拉德茨基进行曲

从目前看到的曲目单上,2019年的新年音乐会将演出6位作曲家的20首曲目,可能还会有一首未公布的加演曲目(原因是虽然飞奔快速波尔卡也很适合作为加演曲目,但是按惯例一般不会以圆舞曲作为正式曲目的最后一首,所以推测在飞奔后面应该还有一首快速波尔卡才是加演第一首)。除了施氏家族的四位成员,另外两位作曲家的名字也是新年音乐会爱好者所耳熟能详的:齐雷尔和约瑟夫·赫尔梅斯伯格。2019年是作曲家弗兰兹·冯·苏佩诞辰200周年,苏佩也是新年音乐会老朋友了,他的著名作品《轻骑兵序曲》曾两次入选新年音乐会的曲目单,今年没有选择他的作品纪念他的诞辰可谓是不按套路出牌。

音乐会的上半场,有两首新曲子,《特快列车波尔卡》是其中的一首,上半场另外还有一首《特快邮车》也是火车体裁的。在施特劳斯的时代,正是火车刚刚开始蓬勃发展的时代,所以他们有不少作品是有关火车的。还记得十多年前在深夜在南京站拍摄9列进京直达特快列车过站视频,后期制作时,我就选用了几首施特劳斯的与火车相关的作品作为背景音乐,很是应景。

下半场是经典怀旧时间,除了4首新曲以外,其它的曲子都是在新年音乐会上多次演出的经典曲目。其中我比较期待的是《艺术家的生活圆舞曲》和《查尔达什舞曲》,前者旋律优美,后者节奏奔放,都曾经给我留下深刻的印象。至于《天体乐声》,这个曲子的旋律也是我喜欢的类型,可这个曲子实在是演出次数太多了,经典的演绎也很多,所以反倒是没有太多期待。这就像是加演的最后那两首,刚开始听新年音乐会时,前面的曲目都不重要,就等着听这两首。而现在,这两首倒像是看完电影以后的字幕了——当然,不是说它们不重要,我看电影也是从来都是要把字幕完整看完的,如果没有它们,这就不是一场完整的新年音乐会(2005年新年音乐会是我心中永远的遗憾)。

……

这年头,资讯太发达了。早年想了解新年音乐会的相关信息,中央电视台的专题和直播几乎是唯一的渠道。而现在,就因为我没有在看到曲目单的第一时间就写完这篇文章,没过几天,网上类似体裁的文章已经是铺天盖地,一篇比一篇专业,一篇比一篇挖掘的深入。如果我再把别人写过的东西再抄一遍,意义也不大。收笔了。

最后提供一点相关的链接,有兴趣的朋友可以继续探索:

用NVME提高群晖NAS的性能

群晖的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的话是单点),需要留意其中的风险