也许有一些兼容性问题？
我的印象是，对于基于 Intel 的系统，Intel 编译器可能比 GCC 做得更好。也许已经有一个发行版尝试过这个？
我认为使用 Gentoo 可能非常简单。
我一直在通过稀疏文件的虚拟设备将 linux 上的 zfs raidz 池迁移到新磁盘。我在磁盘上使用了分区，因为磁盘的大小各不相同，每个 1.9T。要添加的最后一个磁盘是 4Tb 磁盘，我将它与其他磁盘分区，并使用 1.9T 分区添加到池中。它使用 GPT 分区表。当我尝试用 4T 磁盘上的 1.9T 分区替换最后一个文件时，我得到以下信息
zpool replace -f zfs_raid /zfs_jbod/zfs_raid/zfs.2 /dev/sdd1
cannot replace /zfs_jbod/zfs_raid/zfs.2 with /dev/sdd1: devices have different sector alignment
我如何将分区扇区大小更改为 512 像其他人一样，或者如果失败，是否可以将其他池设备更改为 4024 ？显然逻辑扇区大小都是 512
cat /sys/block/sdd/queue/hw_sector_size
Disk /dev/sdd: 4000.8 GB, 4000787030016 bytes, 7814037168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
由于我重新分区了包含我试图替换的基于第 4 个文件的原始设备的光盘，但它不起作用，我重新创建了设备文件，因此它目前正在重新同步该文件。
zpool 状态输出： …
我看到使用 kubernetes 可以为某些工作负载设置节点关联。我想知道在各种容器技术（例如 docker、rocket 等）中是否有任何设施可以让您将进程固定到核心？或者这在多租户环境中是否可行？也许这意味着裸机设置？
大多数主流文件系统都可以相当可靠地增长，但如果我想将来缩小规模怎么办？
XFS 不参加比赛。Reiser 似乎有很好的支持，但给出了可怕的 BETA 警告，但它运行得非常快。Btrfs 似乎承诺好的事情，但我没有这方面的经验。
我想在两台服务器之间传输一个目录，但在传输之前压缩远程主机上的目录，然后解压缩到另一台主机。我确信有可能将所有东西都通过管道输送并在一个衬里中完成。
我意识到如果我可以直接在主机之间传输当然会更好，但这会涉及传输密钥等等，而且我喜欢 Unix 单线电源工具。我相信人们可以想出几种不同的方法来做到这一点。我正在寻找最短的语法和最保守的带宽。
首先我有
ssh -n REMOTEHOST 'tar zcvf - DIRTOCOPY' | localZip.tar.gz
我无法想象没有一个简单的策略来解决这个过时的 nfs 句柄阻止机器正常关闭的问题，但我不确定那会是什么。在观看无休止的“等待 nfsmount”消息时，仅仅因为 wifi 连接在某个时候掉线而不得不强制重启是非常烦人的。
我的目标不是安全地擦除数据，而是简单地通过驱动器固件强制重新分配扇区。
我有一个驱动器有一些文件损坏。这似乎是由于过去某个时候变得非常热，报告的最高温度是 99C！我已经使用 ntfsclone --rescue 从中恢复了尽可能多的数据并安装了映像。
重新分配的扇区数为零，但当前挂起的扇区数为 233。
如果我写入扇区，那么它们将被重新映射或恢复它们的状态，我想知道哪个更快 badblocks -w 或 dd 或其他什么？
我用 iotop 观察到 badblocks 的写入速度约为 17Mb/s，我认为这对于这个驱动器来说不是很快。来自 /dev/zero 的 dd 大约为 24Mb/s，但它经常暂停，平均速度似乎约为 13.5Mb/s，对于这个驱动器来说似乎又太慢了。按照这种速度，将驱动器归零需要一整天的时间。
也许我没有正确使用 dd 并且有更好的方法来进行大型顺序写入。
我一直在玩弄 ZFS，终于接受了它足够成熟我不应该被烧毁的事实。
现在迁移家庭 NAS 盒，它目前是一个 LVM JBOD 设置，它已经很满了，但我只有一个驱动器上有相当多的空间未分配。
我一直在使用在稀疏文件上创建的 zpools 来试验 zfs。用物理分区替换基于文件的 vdevs 似乎是一种非常灵活的前进方式。
我想知道如果我将这个想法发挥到极致，在这个已经非常完整的文件系统中创建与现有硬件相同大小的稀疏文件 vdev，并将内容从 LVM 移到 ZFS 阵列中，会发生什么.
理论上，只要 LVM 文件系统上的可用空间足以容纳不断增长的 ZFS，随着文件从其中删除，它就会继续运行。然后最终 LVM 文件系统将是空的，除了可以用物理分区替换的实际 ZFS 映像。
我预计至少会由于碎片化而对性能产生严重影响。
从表面上看，这听起来很疯狂，为什么要将文件复制到同一文件系统上的另一个容器中。所以我相信这个数据集将受益于打开重复数据删除和压缩，因此最终可能会有更多的可用空间。主要目标是获得将数据放在 ZFS 池中的灵活性，该池可以升级它的“驱动器”，即用物理硬件替换