nas有关TeraByte大小与CPU功耗的问题，用于基本数据存储

处理存储所需的处理能力取决于许多因素。 现在存储处理是一个分布式的过程。 但遇到处理的各个地方：

• 文件共享协议 。 SMB，AFP，NFS和iSCSI对加载都有其自身的影响。 代码质量也有重大影响; Mac可以使用AAT支持的netatalk软件包来扩展比基于Linux的NAS更远的AFP方式。 3.0 Samba的行为比3.6 Samba差。
• 内核I / O例程 。 有些内核比其他内核更有效地处理I / O。 2.6.4时代的Linux内核的performance不如2.6.28或2.6.36。
• 软件与硬件RAID 。 如果使用软件奇偶校验RAID（R5或R6），I / O操作涉及的CPU可能会变得非常重要。 但是，如果你是条纹（RAID1或RAID10，或强烈推荐的RAID0），它几乎不会抽动针。 如果你使用的是硬件RAID，它们通常会在达到极限之前扩展很多，但是在那个时候你的CPU负载并不重要。
• networking堆栈 。 蹩脚的网卡驱动程序可能会导致CPU高峰。 很难预测。

以上所有提供了处理多个应用于传入的存储请求。 纯写入I / O的6.2 MB / s会产生一定数量的负载，但系统所承受的负载范围可以忽略不计，也可能由于所有上述因素的影响而消失。

例如，实际服务器硬件上的Windows Server 2008R2和硬件RAID控制器上的一对磁盘可以在白天和夜晚都达到6.2 MB / s，即使在相对较旧的64位Pentium上也几乎不会出汗（不好的驱动程序） 4个CPU。 基于Core2处理器的FreeNAS在AFP上的写入速度可能跟不上。

存储太字节是CPU负载的一个非常糟糕的预测器，这是一个很长的路要走。

这个关系不是一个纯粹的空间：cpu问题。 根据您所瞄准的解决scheme，您可能需要使用CPUfunction来执行重复数据删除，压缩，encryption或散列/校验和计算等function。

一个简单的数据复制过程不会招致太多的CPU开销，除非你有一个非常糟糕的devise系统。 您的每18小时100 GB的需求将平均为1,58 MB /秒 – 即使上网本也能够应付这种情况。

你也应该专注于你正在使用的I / O后端。 虽然写入1,58 MB /秒听起来不是非常有挑战性，但是使用50-100个同步进程会产生大量的随机写入负载。 硬盘不能很好地处理随机（写入）负载，因为这会导致大量的时间密集型磁头寻找，因此您需要拥有一些缓冲随机性的东西 – 如DRAM或SSD写入caching。