在为 zfs 卷提供服务时，Samba 的“严格分配”的正确选项是什么？
这是一个布尔值，用于控制服务器中磁盘空间分配的处理。当将其设置为“是”时，服务器将从 UNIX 行为（文件扩展时不提交实际磁盘存储块）更改为 Windows 行为（文件创建或扩展为给定大小时实际强制磁盘系统分配实际存储块）。在 UNIX 术语中，这意味着 Samba 将停止创建稀疏文件。
此选项实际上是为支持快速分配大量块的文件系统（如基于扩展的文件系统）而设计的。在不支持扩展的文件系统（最明显的是 ext3）上，这可能会使 Samba 变慢。当您处理超过
在没有扩展的文件系统上，100MB 甚至可能会遇到客户端超时的问题。
当您拥有基于范围的文件系统时，我们很可能可以利用未写入的范围，这允许 Samba 快速分配甚至大量的空间，并且您不会看到由严格分配引起的任何超时问题。使用严格分配时，如果您使用配额，您还可以更好地了解配额消息。激活此设置的另一个优点是它将有助于减少文件碎片。
为了让您了解此设置目前对您来说可能是个不错的选择，请了解哪些文件系统：Linux 上的 XFS、ext4、btrfs、ocfs2 和 AIX 上的 JFS2 支持未写入扩展区。在不支持它的文件系统上，预分配可能是一项昂贵的操作，您将看到性能下降，并且客户端在创建大文件时可能会遇到超时风险。例如 ext3、ZFS、HFS+ 和大多数其他文件系统，因此请注意，如果您在这些文件系统上激活此设置。
默认值：strict allocate = no
因此，如果我有strict allocate = yes，Samba 将不会进行预分配，这在 ZFS 上没有性能优势？
答案1
和strict allocate = yes桑巴将要预分配空间。由于 ZFS 没有基于范围的分配，手册页指出这比 慢strict_allocate = no。
您可能会认为，如果您提前告诉 fs 为您的大文件分配整个空间，那么与逐块分配相比，该空间连续的可能性更高；但是，我不确定 zfs 是否也是如此，因为它力求使所有数据写入都是连续的。如果您启用了压缩，情况肯定不会如此，因为预分配的空间将为空，并将压缩为单个块，因此启用压缩不会给您带来任何好处strict_allocate。
值得一提的是，我尝试fallocate -x在压缩的 ZFS 实例上创建一个 10GB 的文件，花了 2 分钟，这对于 CIFS 客户端来说可能太长了。strace输出显示分配是使用数百万个pwrite64()调用完成的。实际fallocate()调用不受支持：
fallocate(3, 0, 0, 10000000000) = -1 EOPNOTSUPP (Operation not supported)
这是相当新的 zfsonlinux git master。
基于上述内容，我认为strict_allocate在压缩文件系统上启用它是无用的并且会造成极大的破坏；对于禁用了重复数据删除的未压缩文件系统，它可能只会造成极大的破坏，但不一定无用。