简介

作为一个NAS系统，Truenas Scale虽然功能强大，为我们提供了优雅的ZFS支持，但显然不是一个开箱即用的方案。Truenas的官方文档(https://www.truenas.com/docs/scale/scaletutorials) 中已经介绍了大部分基础的操作，已经足够大部分人用上这个系统。不过在使用的过程中仍然会出现一些不影响系统运行，但是让人很难受的小问题，这里分享一下我的解决方案。

重命名Pool

显然，Pool起什么名字是不影响系统运行和用户使用的，但是改变Pool的名字就会影响了。因此在创建Pool之后，系统不允许你重命名Pool。然而Pool的名字毕竟是要经常打的，如果你创建Pool的时候起名不太谨慎，脸滚键盘起了个名字，那有没有办法可以解决呢。

如果你的zfs是运行在cli上的，显然只需要用新的名字重新导入这个Pool就实现了重命名。而在Truenas的gui中，我们主要利用的就是这个。

1. 首先，在Truenas的gui中弹出Pool，记得不要选中清空数据。
   
2. 连接Truenas的linux终端，输入以下命令进行cli的重命名。

   zpool import xxx(旧名字) yyy(新名字)
   zpool export yyy(新名字)

3. 在Truenas的gui中重新导入Pool，显然gui已经识别出新名字的Pool。

共享数据集

权限映射

我们常在Windows的客户端上使用SMB来共享文件，在Linux的客户端上则是NFS。SMB在连接时通常需要进行用户验证，因此SMB是可以分辨在共享文件夹上写入的是哪个用户。但是NFS是没有用户验证的，因此写入的时候就是以Linux客户端的用户写入。于是我们就会发现一个问题：Linux客户端传过来的文件换一台客户端就没权限用。这是为什么呢？

# Truenas
id links
# uid=3000(links) gid=3000(links) groups=3000(links),545(builtin_users),0(root)

# Ubuntu
id links
# uid=1000(links) gid=1000(links) groups=1000(links),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),999(docker)

可以看到，我们在NAS和Ubuntu客户端查找同一个用户的uid，但是在NAS的系统中，links的uid是3000，而在Ubuntu客户端中则是1000。因此如果Ubuntu客户端使用NFS向共享文件夹中写入数据，数据的所有者就是uid=1000，如果恰好权限是755，你uid=3000就没得用了。

这个问题有多种解决的方案：

1. 毕竟在NAS上有root权限，全部sudo chown成需要的owner就好了。坏处可想而知，麻烦。
2. uid相同就行了呗。在NAS上创建一个uid=1000的用户shareuser，为其分配在各个数据集上的权限，用以接收NFS回传的文件。坏处是在Linux的客户端上增加了新用户，就必须同步增加uid相同的新用户。
3. 利用NFS的权限映射功能。我们可以为每个共享的文件夹分配一个Map user，所有的Linux客户端写入这个共享文件夹时，都会自动将owner映射为你设置的user。我们把Map user设置为NAS上的用户。当然，这个map功能不仅如此，还可以映射组，这个可以自己尝试。

我们在NFS共享的文件夹设置中找到Advanced Options。

修改Mapall User和Group就可以了。

容量显示不正确

ZFS的池通过SMB共享后只会显示总的空闲容量，而不是我们在Windows中常见的占用-总容量的格式。我们可以通过为SMB共享文件夹增加一个zfs_core:zfs_space_enabled = yes参数解决这个问题。

数据保护

Truenas除了提供一般NAS系统都有的硬盘阵列功能，还基于ZFS特性提供了更多的数据保护，保证数据的完整性和一致性。

阵列重建

既然使用了Truenas作为系统，显然你是一个硬盘很多的人，并且需要使用硬盘阵列和ZFS的一些特性，比如我。

除了Raid0（不会有人真开Raid0裸奔吧），其他的阵列方案都多多少少存在一点冗余。那么意外发生的时候，我们要怎么利用这些冗余重建我们的数据呢。
首先我们要确认现在的情况，可以在Pool Status看到现在的阵列健康状态。

我们将情况分为以下几类：

1. Pool Status:Online，但是Total ZFS Errors不为0。
   这说明你的阵列出现了一点小问题，但是还在ZFS系统可以handle的范围内，这种情况又分为几种情况。
   首先你要知道每个硬盘都存在一个Unrecoverable Read Error Rate(URE)，其意思是你的硬盘健健康康，还是会存在一些概率使得某个位读不出来。
   
   一般的企业级硬盘这个数字都是1/10E15，出现这个问题的时候就会给Total ZFS Errors+1。所以如果你的Total ZFS Errors是1-2，并且你认为自己是被URE选中的天选之人，那么你应该直接当作无事发生，但是这个Errors看起来还是略有不顺眼，你可以在cli中执行zpool clear <poolname>来清除这个错误。\

2. Pool Status:degraded，但是硬盘还没Offline。
   如果你自觉从小到大并无什么成为天选之人的征兆，或者你的Total ZFS Errors更多一点，那你就应该怀疑自己的硬盘确实出了一点小问题。幸运的是，ZFS系统可以检测出这些读写校验值不一致的小问题，和非ZFS的阵列不同，ZFS在Total ZFS Errors超过一定数量时就会直接对阵列进行降级，而不是等待一个硬盘彻底损毁后才降级。目前，你的硬盘还可以handle这些问题，因为硬盘中也会为坏道保留一些冗余的块，避开对坏道的读取写入。这时，建议你马上对出现错误的硬盘进行S.M.A.R.T. Test，一般可以看到硬盘出了什么问题，然后再决定是要更换硬盘或是接着clear之后再用一段时间。如果硬盘没有任何问题，则可能是线缆出了点小问题，可以更换连接硬盘的线缆，恢复正常使用。

3. Pool Status:degraded，硬盘Offline。
   你的硬盘已经挂了，但是还在整个硬盘阵列的容忍范围之内，所以你的数据还没有完全损毁。当然，更换硬盘并重建阵列是必要的，但是在这之前，你要了解：如果你的硬盘已经挂了，那你阵列中其他的硬盘状态多半好不到哪里去。而重建阵列需要把阵列中其他硬盘全部读取一遍计算校验值写入新硬盘，有很大的概率在这个过程中又要挂一块，那你的数据就完全损毁了。如果你的数据很重要，那么你需要
   立即备份重要数据
   立即备份重要数据
   立即备份重要数据
   或者你平常就有定期备份数据的好习惯，那么你可以检查一下备份数据还是否可用以及和目前数据的一致性。
   接下来在Storge - Manage Devices中找到挂掉的硬盘，在Disk info中选择replace换成你的新硬盘。系统将自动开始阵列重建，在ZFS中，这个过程被称为Resilver。
   
   重建过程将耗费远超重新写入所有数据的时间，作为参考，我写入27t数据用了一天半，而重建这么多数据则用了七天。因此，如果你的其他硬盘也接近了寿命极限，我建议直接送去闲鱼。然后购买全新的硬盘组成阵列后从备份中恢复数据。