在创建个人数据湖的目标并通过 向其中填充了大量 TB 的数据后rsync，我在下次重启时感到非常惊讶，Ubuntu 的 ZFS 不喜欢这些数据集，并在下次导入时自动销毁它们。
zpool history -il epool
2020-04-28.23:20:34 [txg:16285] open pool version 5000; software version unknown; uts acacia 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 [on acacia]
2020-04-28.23:20:35 [txg:16287] import pool version 5000; software version unknown; uts acacia 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 [on acacia]
2020-04-28.23:20:40 zpool import -c /etc/zfs/zpool.cache -aN [user 0 (root) on acacia:linux]
2020-04-28.23:30:44 [txg:16409] destroy epool/USERDATA/edata/pub (600) [on acacia]
...
2020-04-28.23:31:35 [txg:16451] destroy epool/USERDATA/edata/home (702) [on acacia]
2020-04-28.23:31:38 [txg:16453] destroy epool/USERDATA/edata/data (607) [on acacia]
2020-04-28.23:31:41 [txg:16455] destroy epool/USERDATA/edata/src (902) [on acacia]
2020-04-28.23:31:43 [txg:16457] destroy epool/USERDATA/edata (70) [on acacia]
可能是
- zpool 的加密密钥尚未加载/不再加载，丢弃数据集是否更安全？
- 关机时没有
zpool.cache更新吗？ zsys，之前曾抱怨未配置的池，以某种方式将其标记为需要处置？
zpool 本身报告状况良好。
zpool status -v epool
pool: epool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
epool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
usb-Seagate_Expansion_Desk_NAAAQA7P-0:0 ONLINE 0 0 0
usb-Seagate_Expansion_Desk_NAAAQAAR-0:0 ONLINE 0 0 0
errors: No known data errors
没有挂载点的高阶数据集也幸存了下来。
NAME USED AVAIL REFER MOUNTPOINT
epool 22,4M 7,04T 192K none
epool/USERDATA 192K 7,04T 192K none
运行命令时出现有关这两行之间缺少关联的警告apt，但我无法再重现输出：
INFO Requesting to save current system state
Successfully saved as "autozsys_q7gdq0"
查看日志zsys-commit发现了同样的投诉，即上次重启后，最终在启动破坏性操作之前，自定义数据集缺少关联；或者因为它？
root@acacia:~# journalctl -b -3 -u zsys-commit
-- Logs begin at Thu 2019-10-31 19:08:10 CET, end at Wed 2020-04-29 01:45:14 CEST. --
-- No entries --
root@acacia:~# journalctl -b -2 -u zsys-commit
-- Logs begin at Thu 2019-10-31 19:08:10 CET, end at Wed 2020-04-29 01:45:14 CEST. --
Apr 22 23:10:24 acacia systemd[1]: Starting Mark current ZSYS boot as successful...
Apr 22 23:10:25 acacia zsysctl[16934]: INFO Updating GRUB menu
Apr 22 23:10:34 acacia systemd[1]: Finished Mark current ZSYS boot as successful.
Apr 22 23:22:05 acacia systemd[1]: zsys-commit.service: Succeeded.
Apr 22 23:22:05 acacia systemd[1]: Stopped Mark current ZSYS boot as successful.
root@acacia:~# journalctl -b -1 -u zsys-commit
-- Logs begin at Thu 2019-10-31 19:08:10 CET, end at Wed 2020-04-29 01:45:22 CEST. --
Apr 23 00:37:53 acacia systemd[1]: Starting Mark current ZSYS boot as successful...
Apr 23 00:37:54 acacia systemd[1]: Finished Mark current ZSYS boot as successful.
Apr 26 15:11:01 acacia systemd[1]: zsys-commit.service: Succeeded.
Apr 26 15:11:01 acacia systemd[1]: Stopped Mark current ZSYS boot as successful.
root@acacia:~# journalctl -b 0 -u zsys-commit
-- Logs begin at Thu 2019-10-31 19:08:10 CET, end at Wed 2020-04-29 01:45:22 CEST. --
Apr 28 23:20:44 acacia systemd[1]: Starting Mark current ZSYS boot as successful...
Apr 28 23:20:48 acacia zsysctl[3918]: WARNING Couldn't find any association for user dataset epool/USERDATA/edata
Apr 28 23:20:48 acacia systemd[1]: Finished Mark current ZSYS boot as successful.
它是ZSYS垃圾收集器，它揭示了更多的破坏意图：
journalctl -u zsys-gc.service
-- Logs begin at Thu 2019-10-31 19:08:10 CET, end at Wed 2020-04-29 01:50:34 CEST. --
Apr 22 23:10:24 acacia systemd[1]: Starting Clean up old snapshots to free space...
Apr 22 23:10:25 acacia systemd[1]: zsys-gc.service: Succeeded.
Apr 22 23:10:25 acacia systemd[1]: Finished Clean up old snapshots to free space.
-- Reboot --
Apr 23 00:47:46 acacia systemd[1]: Starting Clean up old snapshots to free space...
Apr 23 00:47:46 acacia systemd[1]: zsys-gc.service: Succeeded.
Apr 23 00:47:46 acacia systemd[1]: Finished Clean up old snapshots to free space.
Apr 24 22:09:25 acacia systemd[1]: Starting Clean up old snapshots to free space...
Apr 24 22:09:27 acacia zsysctl[7224]: WARNING Couldn't destroy unmanaged user dataset epool/USERDATA/edata: couldn't destroy "epool/USERDATA/edata" and its children: stop destroying dataset on "epool/USERDATA/edata", cannot destroy child: cannot destroy dataset "epool/USERDATA/edata/pub": dataset is busy
Apr 24 22:09:27 acacia zsysctl[7224]: WARNING Couldn't find any association for user dataset epool/USERDATA/edata
Apr 24 22:09:27 acacia systemd[1]: zsys-gc.service: Succeeded.
Apr 24 22:09:27 acacia systemd[1]: Finished Clean up old snapshots to free space.
-- Reboot --
Apr 28 23:30:24 acacia systemd[1]: Starting Clean up old snapshots to free space...
Apr 28 23:30:38 acacia zsysctl[23544]: WARNING Couldn't find any association for user dataset epool/USERDATA/edata
Apr 28 23:31:45 acacia systemd[1]: zsys-gc.service: Succeeded.
Apr 28 23:31:45 acacia systemd[1]: Finished Clean up old snapshots to free space.
这里没有明确提到破坏，但我们可以将其与之前的日志联系起来。
我了解运行实验性 ZFS 支持系统的风险。它的bpool和rpool也保持完好。我担心的是用户数据会在未经同意甚至未明确通知的情况下自动销毁。这既不是明智的默认设置，也不支持 Ubuntu 中的整体 ZFS 实验，并且给人留下了对新 Canonical ZSYS 服务的实施质量的怀疑印象。
最终，这里需要标记为实验性的并不是 ZFS，因为它在广泛的安装中坚如磐石，而是产生标志的 ZSYS 集成。
在哪里可以直接向 Canonical 上游报告此问题？Launchpad 上的某个地方？我主要想避免向 OpenZFS 开发人员提出这个问题，因为我认为这是 Ubuntu 自己的 ZFS 维护和支持的问题。
missing_300_reputation_for_new_tags: ["zsys", "zpool"]