李守中

群晖相关

Table of Contents

1. 群晖修改底层组件保证数据完整性 (修复静默错误)

1.1. 公版 btrfs over lvm over mdadm 的组合不保证数据完整性

思路:

  1. 使用 btrfs, lvm, mdadm 官方的代码，未经改动
  2. 模仿群晖的存储结构: btrfs over lvm over mdadm 而不使用 btrfs 自带的 raid 功能
  3. 执行 btrfs scrub 和 mdadm scrub 以解决静默错误问题
  4. 对于 btrfs scrub 来说:
    1. btrfs 跑在 lvm 创建出的逻辑卷上，使用默认配置，存储 2 份 metadata 和 1 份 data
    2. 默认配置导致 btrfs 的 self-healing 对 data extent (不包含 metadata extent) 不生效，导致无法保证 data extent 的完整性
    3. 2 盘 md raid1，这意味着在物理存储层中 metadata 有 4 份，data 有 2 份，btrfs 的 self-healing 也只能看到 2 份 metadata 和 1 份 data。因为 btrfs 看不到 mdadm 存储了什么东西，btrfs 只能确定自己存过的 2 份 metadata 和 1 份 data 是有效数据
    4. 所以 btrfs 无法使用 mdadm 层面的热冗余来恢复损坏的 data extent
    5. 所以这种 btrfs 的用法导致存储系统无法保证 data extent 的数据完整性
  5. 对于 mdadm scrub 来说:
    1. mdadm 检测到 block error 时，对于 raid1 就从第一个盘取数据然后搬到其他盘，对于 raid5/6 就根据现有数据重新计算校验和
    2. 由于以上行为，mdadm 在文档里写明，mdadm 不能保证数据完整性。以上行为的目的是让 mdadm 正常运行，而不是修复损坏的数据
  6. 这种存储方案中的每一层都无法保证数据完整性
  7. 所以这种存储方案无法保证数据完整性

下面补充一下细节，不想看可以跳过。

探索第一阶段 btrfs scrub 中 self-healing 这个功能的底层实现。

群晖存储系统的结构为: 先用 mdadm 创建存储设备，并映射为以 md 开头的 block device；md device 作为 pv 交由 lvm 管理；lvm 在 pv 上创建 vg ，进而创建 lv；最后把 btrfs 放在 lv 上。即，btrfs over lvm over mdadm。

btrfs 会记录每个 extent 的 checksum 值用于验证这个 extent 中的数据是否完整，命令 btrfs scrub 可以触发 self-healing。在 self-healing 过程中，修复 checksum 有异常的数据需要额外的，具有正常的 checksum 的另一份数据。即，触发 self-healing 需要 btrfs 中的数据有热冗余。

比如，btrfs 在 Linux 上 btrfs 默认存储两份 metadata 用于在 metadata 损坏时修复这些损坏的 metadata，而 data 则只存了一份，所以在这种情况下，如果 data 的 checksum 出现异常则无法修复。在这个例子中，metadata 有热冗余，data 没有，所以 metadata 可以利用 self-healing 修复 corrupted metadata，而 data 不行。

需要注意: 2 盘 raid1 意味着在物理存储层中 metadata 有 4 份，data 有 2 份，但 btrfs 的 self-healing 只能看到 2 份 metadata 和 1 份 data。因为 mdadm+lvm 屏蔽了 btrfs 对于底层存储结构的感知。即使 mdadm 确实有热冗余，但 btrfs 看不到，所以 btrfs 无法使用 mdadm 中的热冗余。btrfs 能看到的、能用的只有 btrfs 存过的东西 (存过 2 份 metadata 和 1 份 data)。

继续探索第二阶段 mdadm scrub 中 mdadm 都做了什么。

我从 raid.wiki.kernel.org 找到:

下面举个例子以证明 mdadm 在 raid1 中检测到数据不一致时，mdadm scrub 无法保证修复错误数据:

  1. mdadm 把主盘上损坏的数据返回给了 btrfs，btrfs 看见了主盘上损坏的 data extent
  2. 主盘是最先发生读写的盘，所以当负载较小时，btrfs 多数时候都能检测到 data extent corruption
  3. 但由于 btrfs 只看到一份 data extent 所以 btrfs 的 self-healing 无法生效
  4. mdadm 开始 scrub，把主盘上的有了问题的数据覆写到从盘上
  5. 此时数据彻底损坏，但 mdadm 报告修复成功

下面举个例子以证明 mdadm 在 raid5/6 中检测到数据不一致时，mdadm scrub 无法保证修复错误数据:

  1. raid5/6 中数据部分出现问题
  2. mdadm 根据错误数据重新计算校验和
  3. 原来校验和是对的，现在校验和也错了，但 mdadm 报告修复成功

以上两个例子都是 mdadm scrub 无法修复数据的情形。

如前文所述，跑在逻辑卷上的 btrfs 的默认配置无法保证 data extent 的完整性；而原版 mdadm 的行为，如文档所说，也不保证数据完整性。

所以结论是，对于使用公版 btrfs over lvm over mdadm 的做法来说，做 fs scrub + raid (mdadm) scrub 的成果是，修复影响 btrfs over lvm over mdadm (over LUKS) 这套组合正常运行的问题，而由于 mdadm 暴露给 btrfs 的，btrfs 能看到的数据没有变化，所以 btrfs 在 data extent (不包括 metadata extent) corruption 出现时，不能修复已损坏的 data extent，最终，用户已损坏的 data extent 保持在已损坏状态，需要用户介入。

1.2. 群晖定制后 btrfs 可以利用 mdadm 的冗余数据修复 data extent

我找不到群晖对于 btrfs 的定制部分的代码，这部分没有开源。但通过模拟数据损坏可以确定群晖对 btrfs 有修改。

后文的一些步骤与命令参考了 https://daltondur.st/syno_btrfs_1/ 中的内容，但这篇文章只测了 SHR-1 (一种群晖魔改的 raid5) 而没有测 raid1，所以我自己测了一下 raid1 相关的行为。

从结果来看，群晖上的 raid1 在对抗静默错误的方面不如 raid5/6 及其变种 (SHR)。

用到的工具:

  1. VMWare Workstation 15 用于打开从其他网站下载来的黑群晖系统
  2. 李佑辰 制作的 DS3615xs DSM 7.1 系统 (系统是随便选的，作者名字是从虚拟机描述里面找到的)
  3. HxD 用于修改 .vmdk 文件中的数据。Emacs 的 hexl-mode 也行，只是操作 4G 的 .vmdk 文件特别特别慢

1.2.1. raid1 主盘上的数据会被自动修复

验证过程中需要注意的地方:

  1. 创建硬盘时要创建 SATA 硬盘，否则不识别
  2. 创建硬盘时推荐使用 30G 大小 (2 盘 raid1 后有大约 19.8G 可用空间)
  3. 创建硬盘时，选定 '将虚拟磁盘存储为单个文件' 方便使用 HxD 工具修改数据
  4. 创建 2 个存储池
    • 第一个存储池用 basic 模式，第二个存储池使用 raid1 用于验证 self-healing
    • 群晖会把套件内的数据放在第一个存储池上，所以如果只有一个存储池的话，模拟数据损坏时找数据很费力
  5. 使用 HxD 从 .vmdk 文件中找数据时，要注意找对测试文件，用对应字节序列后跟数个 0 来检索可以更快定位到文件结束的位置
  6. 创建测试文件之后，文件要等一会才会被从缓存中搬到硬盘上，所以创建文件后要等一会才能在 HxD 中找到文件结尾
  7. 关闭虚拟机的目的是清除内存里面的文件系统缓存
  8. 读取彻底损坏的数据，或 '数据清理' 遇到彻底损坏的数据时，群晖套件的日志中心才有文件的校验和不匹配的警告

后面说的快照并不是 VMWare 自带的磁盘快照，而是手动复制整个 VM 目录！！！

下面模拟群晖 raid1 上的数据损坏:

  1. 硬盘 1 是启动盘不用动，硬盘 2 用 basic 模式创建存储池 1
  2. 用硬盘 3 4 创建 raid1 存储池 2，建立共享文件夹 lol。注意硬盘 3 在硬盘 4 之前，即，硬盘 3 是 raid1 的主盘
  3. 建立快照 1
  4. ssh 登入后，cd 到共享文件夹内执行 dd if=/dev/zero bs=4096 count=262144 | tr '\000' '\377' > FF 生成 1G 大小的名为 FF 的文件 (文件内数据的 16 进制表示也是 'FF') 并计算 sha256sum FF
  5. 关闭虚拟机，建立快照 2
  6. 用 HxD 打开硬盘 3 4 对应的 .vmdk 文件，按字节序列查找，用 'FFFF0000' 定位到最后一个匹配，这里有几个坑:
    • btrfs 有些系统数据也包含了很多连续的 'FF'，所以不好分辨 FF 文件的起始地址
    • 由于 btrfs 的写是事务操作，所以 FF 文件的 extent 分布有时并不连续，所以 FF 文件起始地址的特征并不明显
    • 但是硬盘中 FF 文件结束地址的特征很明显，从我的实际操作来看，在 .vmdk 文件的后半部分会有几百 M 充满了 'FF' 的空间，这段充满 'FF' 空间的末尾，就是 FF 文件的末尾
  7. 在 HxD 打开的硬盘 3 中，将 FF 文件末尾的 'FF' 改成 'FE' 模拟 1 bit 的损坏，记录地址，保存硬盘 3
  8. 打开虚拟机，建立快照 3
  9. 用 ssh 登入到群晖系统，计算 sha256sum FF 可以得到与刚才相同的校验和，刷新 HxD 中硬盘 3 的视图后看到 'FE' 变回 'FF'

上述流程执行完后，从 /var/log/messages 里面可以看到这样的日志: 

2023-11-05T11:26:22+08:00 tdsm kernel: [  670.533439] BTRFS warning (device dm-4): csum failed ino 262 off 1041494016 csum 3618274576 expected csum 633470483
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.533579] md3: [Self Heal] Retry sector [3182200] round [1/2] start: choose disk [0:sdf3]
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.534225] md3: [Self Heal] Retry sector [3182200] round [1/2] finished: return result to upper layer
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.537723] BTRFS warning (device dm-4): csum failed ino 262 off 1041494016 csum 3618274576 expected csum 633470483
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.537847] md3: [Self Heal] Retry sector [3182200] round [1/2] start: choose disk [0:sdf3]
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.538034] md3: [Self Heal] Retry sector [3182200] round [1/2] finished: get same result, retry next round
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.539506] md3: [Self Heal] Retry sector [3182200] round [2/2] start: choose disk [1:sdg3]
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.541169] md3: [Self Heal] Retry sector [3182200] round [2/2] finished: return result to upper layer
2023-11-05T11:26:22+08:00 tdsm kernel: [  670.555152] BTRFS: read error corrected: ino 262 off 1041494016 (dev /dev/mapper/cachedev_0 sector 3156472)

可以判断，FF 文件在被读取时检测到损坏，并被修复。

验证结束。下面是补充内容，可以不看。

我从快照 3 开始，尝试了 3 种操作。

第一种，就是上面提到的，通过计算校验和来读取文件。

第二种，手动调用 btrfs scrub 并观察程序的行为。

执行 sudo btrfs scrub start /volume2 开始检查并修复数据，等一会 ssh 终端会回显一行:

WARNING: errors detected during scrubbing, corrected

用 sudo btrfs scrub status /volume2 可以看到有 1 个 error，和 1 个 corrected errors。

然后用 HxD 打开硬盘 3 并定位到模拟数据损坏的位置，可以看到 'FE' 又变回了 'FF'

第三种，从手动执行群晖套件 '存储空间管理' 中的 '数据清理' 功能，并观察日志和文件。结果是，我可以从 /var/log/messages 中看到确实发生了 self heal，但是群晖的日志中心没有任何提示。

此外，我又想到 mdadm raid1 的硬盘分主从，接着我就切到快照 2，在从盘上模拟静默错误，然后就有了下一节的内容。

1.2.2. 发现 raid1 从盘上的数据可能不被自动修复

现在恢复到快照 2 然后:

  1. 用 HxD 打开硬盘 3 4 对应的 .vmdk 文件，按字节序列查找，用 'FFFF0000' 定位到最后一个匹配
  2. 用 HxD 将 硬盘 4 中 FF 文件末尾的 'FF' 改成 'FE' 模拟 1 bit 的损坏，记录地址，保存 硬盘 4
  3. 打开虚拟机
  4. 用 ssh 登入到群晖系统，计算 sha256sum FF 的到了相同的校验和

但是可以从 HxD 中看到，硬盘 4 上，刚才被改成 'FE' 的地方还是 'FE'，并没有变成 'FF'。并且 /var/log/messages 中也没有任何关于 btrfs self heal 相关的日志。

接着手动执行 sudo btrfs scrub start /volume2 。执行完成后没有从日志中找到 btrfs self heal 相关的日志，HxD 中看到硬盘 4 上的数据没有被自动修复。最后调用群晖套件 '存储空间管理' 中的 '数据清理' 功能，同样地，日志内无相关信息，HxD 中看到硬盘 4 上的数据没有被自动修复。

我推测这可能和 mdadm raid1 的读写策略有关: 让硬盘 I/O 总是尽可能地发生在 raid1 的主盘上。在这个策略下，负载较小时几乎不会有发生在从盘上的 I/O，所以从盘上的数据也就几乎不被读取，因此从盘上的静默错误就不会被发现，也就不会触发 self heal 了。

我尝试用 rsync 从别的机器向 vm 内复制数据以增加硬盘压力，从而触发从盘的 I/O，进而让 btrfs scrub 可以检测到从盘的校验和异常，但是没有成功。

最后，来都来了，模拟一下不能修复的情况吧，看看群晖有什么行为。

1.2.3. 不能修复的情况

现在恢复到快照 1 然后模拟数据无法修复的情况:

  1. 使用 dd if=/dev/zero bs=4096 count=262144 | tr '\000' '\364' > F6 创建一个 F4 文件
  2. 计算 F4 文件的 sha256 校验和 (be07b1c8b0898f32100894762e0254b5063c4d331577d5d1396a8604c3257fd8)
  3. 关闭虚拟机，建立快照 2
  4. 用 HxD 打开硬盘 3 4 对应的 .vmdk 文件，找到 F6 文件的结束，同时修改硬盘 3 4 上 F6 文件的最后 4 字节
    • 把硬盘 3 上 FF 文件的最后 4 字节的 'F6F6' 改为 'EEEE' 后保存
    • 把硬盘 4 上 FF 文件的最后 4 字节的 'F6F6' 改为 '0000' 后保存
  5. 打开虚拟机，建立快照 3
  6. 重新计算 F4 的 sha256 校验和 (dd915f47becc7efe8e818aae565dbae97b6bffced103f032b1bc16135122435a)

很明显，两个校验和不一样。然后再看 /var/log/messages 里面的日志: 

2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.847997] checksum error found by scrub at logical 4674465792 on dev /dev/mapper/cachedev_0, mirror = 0, metadata = 0
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.848275] md3: [Self Heal] Retry sector [9696216] round [1/2] start: choose disk [0:sdf3]
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.848824] md3: [Self Heal] Retry sector [9696216] round [1/2] finished: return result to upper layer
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.849202] md3: [Self Heal] Retry sector [9696216] round [1/2] start: choose disk [0:sdf3]
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.849786] md3: [Self Heal] Retry sector [9696216] round [1/2] finished: get same result, retry next round
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.850237] md3: [Self Heal] Retry sector [9696216] round [2/2] start: choose disk [1:sdg3]
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.850878] md3: [Self Heal] Retry sector [9696216] round [2/2] finished: return result to upper layer
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.851330] md3: [Self Heal] Retry sector [9696216] round [2/2] start: choose disk [1:sdg3]
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.851957] md3: [Self Heal] Retry sector [9696216] round [2/2] finished: get same result, retry next round
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.852403] md3: [Self Heal] Retry sector [9696216] round [5/2] error: cannot find a suitable device, bio sector length [8], request_cnt [3]
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.853322] failed to repair csum (scrub) at logical 4674465792 on dev /dev/mapper/cachedev_0, mirror = 0, metadata = 0
2023-11-05T16:23:43+08:00 tdsm kernel: [ 5313.853913] BTRFS: (null) at logical 4674465792 on dev /dev/mapper/cachedev_0, sector 9670488, root 257, inode 267, offset 1073737728, length 4096, links 1 (path: F4)

日志显示无法修复。然后可以从 HxD 里面看到:

  • 硬盘 3 上 F4 的最后 4 字节还是 'EEEE'
  • 硬盘 4 上 F4 的最后 4 字节还是 '0000'

群晖套件的日志中心里还可以找到一条日志: Checksum mismatch on file [/volume2/lol/F4].

我在这里的快照 3 之后尝试了 3 种操作。

第一种，就是上面提到的用 sha256sum 去读损坏的文件。

第二种，建立快照后执行 sudo btrfs scrub start <mount-point> 之后，ssh 的回显会输出 ERROR: there are uncorrectable errors 但群晖的日志中心不会看到警告。

但只要调用群晖套件 '存储空间管理' 中的 '数据清理' 功能，群晖的日志中心就会有警告。

'数据清理' 功能启动后不断地用 cat /proc/mdstat 查看 mdadm 的状态，发现 mdadm scrub 始终没有启动。

第三种，多次执行修复操作看会发生什么。如果用户没有手动修复的话，每次执行 btrfs scrub 或 '数据清理' 都会提示 F4 文件损坏。但在修复之前，硬盘 3 4 上面损坏的数据会保持原样。

1.3. 那 mdadm scrub 呢？

下面只说我观察到的 DSM 的行为，继续用之前创建的 raid1 存储池来观察。从观察结果来看 mdadm scrub 的行为并没有改变。

1.3.1. 主盘数据损坏

切到快照 1 (只建好存储池和共享文件夹) 开始操作:

  1. ssh 连上，切到共享文件夹中 dd if=/dev/zero bs=4096 count=262144 | tr '\000' '\370' > F8 创建 F8 测试文件
  2. cat /sys/block/md3/md/mismatch_cnt 确认不匹配的 block 的数量为 0
    • 如果不为 0 就需要先 echo repair > /sys/block/md3/md/sync_action 再 echo check > /sys/block/md3/md/sync_action 修复问题并刷新 mismatch_cnt 计数，保证 raid 干净之后再做下一步
  3. 关闭虚拟机，建立快照 2
  4. 用 HxD 打开硬盘 3 4 对应的 .vmdk 文件，定位到 F8 文件的末尾地址
    • 将硬盘 3 (主盘) 中的 F8 文件末尾的 'F8' 改成 'F7' 模拟 1 bit 的损坏，记录地址，保存硬盘 3
    • 硬盘 4 不动
  5. 建立快照 3

从快照 3 开始 (以下每一点开始时都会恢复到快照 3 初始状态):

  • 执行 '数据清理':
    • 主盘上的数据被正常修复
    • 不断地用 cat /proc/mdstat 查看 mdadm 的状态，发现 mdadm scrub 始终没有启动
  • 命令行下执行 echo repair > /sys/block/md3/md/sync_action
    1. 硬盘 3 上文件 F8 最后错误的 2 字节 'F7' 被同步到了硬盘 4 上 (现在两份数据都坏了)
    2. 命令行执行 btrfs scrub start /volume2
    3. 命令行回显 ERROR: there are uncorrectable errors 日志中心出现 Checksum mismatch on file [/volume2/lol/F8].

1.3.2. 从盘数据损坏

切到快照 1 (只建好存储池和共享文件夹) 开始操作:

  1. ssh 连上，切到共享文件夹中 dd if=/dev/zero bs=4096 count=262144 | tr '\000' '\370' > F8 创建 F8 测试文件
  2. cat /sys/block/md3/md/mismatch_cnt 确认不匹配的 block 的数量为 0
    • 如果不为 0 就需要先 echo repair > /sys/block/md3/md/sync_action 再 echo check > /sys/block/md3/md/sync_action 修复问题并刷新 mismatch_cnt 计数，保证 raid 干净之后再做下一步
  3. 关闭虚拟机，建立快照 2
  4. 用 HxD 打开硬盘 3 4 对应的 .vmdk 文件，定位到 F8 文件的末尾地址
    • raid1 主盘是硬盘 3，不动
    • 将硬盘 4 中的 F8 文件末尾的 'F8' 改成 'F7' 模拟 1 bit 的损坏，记录地址，保存硬盘 4
  5. 建立快照 3

从快照 3 开始 (以下每一点开始时都会恢复到快照 3 初始状态):

  • 执行 '数据清理':
    • 点击按钮后，快速切到命令行下面执行 cat /proc/mdstat 发现 mdadm scrub 始终没有启动
    • 硬盘 4 上被改成 'F7' 的数据没有改变
    • cat /sys/block/md3/md/mismatch_cnt 始终显示值为 0
  • 命令行下执行 btrfs scrub start /volume2 && cat /proc/mdstat:
    • 不断地用 cat /proc/mdstat 查看 mdadm 的状态，发现 mdadm scrub 始终没有启动
    • 硬盘 4 上被改成 'F7' 的数据没有改变
    • cat /sys/block/md3/md/mismatch_cnt 始终显示值为 0
  • 命令行下执行 echo repair > /sys/block/md3/md/sync_action
    • cat /proc/mdstat 发现 mdadm scrub 启动，等待命令结束
    • cat /sys/block/md3/md/mismatch_cnt 发现其值为 128 (1 page size)
    • 硬盘 4 上被改成 'F7' 的数据变回了 'F8'

1.4. 观察总结

根据观察到的现象:

  • btrfs scrub 可以利用 mdadm 中的冗余来修复 data extent (公版 btrfs 不能)
  • mdadm scrub 的行为并没有脱离 linux kernel 文档的描述

我猜测群晖可能修改了 btrfs scrub 的行为，并在 mdadm 中添加了供 btrfs scrub 调用的接口来实现 btrfs scrub 利用 mdadm 中数据的功能。

结论是，群晖目前使用的存储方案可以保证数据完整性。

(个人认为目前群晖整个硬件上影响数据完整性的，可以控制的因素就在于没有 ecc 内存了)

2. 存储空间 - 记录文件访问时间

这个功能由文件系统中时间标记 (time flag) 中的 atime 实现。

Unix 文件系统中有三种时间标记:

  • atime (access time): 文件上次被读取的时间
  • ctime (status change time): 文件的属性或内容上次被修改的时间 (inode 变动的时间)
  • mtime (modified time): 文件的内容上次被修改的时间

下面的命令可以方便地查看这三个时间标记: 

#!/bin/bash
echo "ctime: $(ls -lc file | awk '{print $6, $7, $8}')"
echo "atime: $(ls -lu file | awk '{print $6, $7, $8}')"
echo "mtime: $(ls -l  file | awk '{print $6, $7, $8}')"

exit 0;

这个功能有三个选项可选，这三个选项分别代表三种 atime 的更新频率:

  • 每天:
    • 满足 创建文件后，首次访问时 或 访问文件时的系统时间 - 当前 atime 记录的时间 > 24 小时 更新文件的 atime
    • atime 更新后，计时器被重置 (即 24 小时之内不会更新 atime)
  • 每月:
    • 满足 创建文件后，首次访问时 或 访问文件时的系统时间 - 当前 atime 记录的时间 > 30 日 更新文件的 atime
    • atime 更新后，计时器被重置 (即 30 日之内不会更新 atime)
  • 永不:
    • 永远不更新文件的 atime (即，在挂载时指定 noatime 选项)

Linux 文件系统没有这三个频率可选，只有开启 (默认) 和关闭 (挂载文件系统时指定 noatime 选项) 两种情况。群晖应该是对文件系统实现做了一些修改才实现了这个根据频率更新 atime 的功能。

经测试，在文件被访问 (即 atime 被更新) 后，重启系统接着立即再次访问该文件，atime 在本轮更新周期结束之前不会再被更改。可见与 atime 更新有关的数据会被持久化到硬盘上。

3. 共享文件夹 - 文件压缩功能

这个功能开关旁边的注解是: 新的压缩规则将仅应用于新添加的文件，已有文件不会受到影响 。

它意味着，只有在文件压缩功能开启期间被写入的数据 (文件) 才会被压缩。在功能开启之前和关闭之后，被写入的文件不会被压缩。

同时，群晖不会主动对已经存在于存储空间中的数据进行压缩和解压缩。

即，如果功能开启前，存储空间已经有数据了，那么功能开启之后，群晖不会主动对已在存储空间中的、未被压缩的数据 (统称 A) 进行压缩；如果功能被关闭，群晖也不会主动对在功能开启期间被写入并被压缩的数据 (统称 B) 进行解压缩操作。

这意味着，一个共享文件夹内，已被压缩和未被压缩的数据可以同时存在。

但是，如果功能开启期间，用户对 A 有了写操作，那么 A 会被压缩并保存在存储空间中；如果功能关闭之后，用户对 B 有了写操作，那么 B 会被解压缩并保存在存储空间中。

注: 以上列举的操作都发生在同一个共享文件夹中。

4. 群晖作为 nut-client

群晖的不断电系统使用了 NUT 作为管理工具。它也可以作为 nut-client 连接到其他的 nut-server。

但是需要 nut-server 使用默认的通信端口，将 UPS 名称设置为 UPS ，并新建一个用户名为 monuser 密码为 secret 的用户。

即，在 nut-server 所在机器上的 ups.conf 中有如下配置: 

# 注意 UPS 名称必须是 'UPS' 才行
[ups]
  driver = "..."
  port = "auto"
  vendorid = "..."
  ...

在 nut-server 所在机器上的 upsd.users 文件中有如下用户: 

[monuser]
  password = secret
  upsmon slave

可以用 SSH 连接到群晖之后，执行 sudo upsc ups@<nut-server-ip> 来检查群晖能否正确与 nut-server 通信。

最后在群晖的不断电系统的 UPS 类型 中选择 Synology 不断电系统服务器 ，然后填入 nut-server 的 IP 即可。

5. 浏览器中无法正确拖动排列主菜单中的应用图标

该问题通常出现在小屏或高缩放率设备上，比如主菜单中一页只能显示 3 行图标，只有这前 3 行图标可以被正确排列。

在使用一个大的显示器打开 DSM 后，一屏就可以显示所有的内容，此时可以正确拖动所有的图标。

群晖的技术支持说，通过 Ctrl + 鼠标滚轮调整浏览器缩放从而让主菜单的一页可以显示更多图标，然后就可以正确拖动排列了。



Last Update: 2023-11-09 Thu 16:05

Generated by: Emacs 28.2 (Org mode 9.5.5)   Contact: [email protected]

若正文中无特殊说明，本站内容遵循: 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议