苟延残喘,回光返照:从Cheetah 10K.7到Cheetah NS

简介:
这个世界上“皆大欢喜”的事情不多,至少对3.5英寸10000RPM硬盘驱动器来说,SAS的兴起便成了其命运的分水岭。15000RPM的Cheetah 15K.4、MAU/MAX3147和Ultrastar 15K147在推出时未能提供SAS支持,是受后者的发展滞后所限;而3.5英寸的10000RPM们,却只有迈拓的 Atlas 10K Ⅴ有SAS版本 ,Cheetah 10K.7、MAW3300和Ultrastar 10K300则压根就没考虑过这回事。
73GB的Cheetah 10K.7,采用80针SCA-2接口(Ultra320 SCSI热插拔)
不支持未来的主流接口,将来Ultra320 SCSI退役了,还有继续存在的必要吗?总不能只靠FC-AL吧?果然,Cheetah 15K.5发布的时候,没有理论上应该发展到的Cheetah 10K.8,而MAW3300和Ultrastar 10K300的接班人也至今都没有出现,Atlas家族更是随着迈拓被希捷并购而不复存在。看来,厂商们的确在有计划地放弃3.5英寸10000RPM硬盘驱动器。
促使他们作出上述决定的原因大致有两个因素。其中之一是容量。以希捷为例,如果在2006年第二季度推出Cheetah 10K.8,按照传统,其容量应该达到10K.7的两倍,即600GB。可是同期的7200RPM硬盘驱动器的容量才多大呢?750GB而已(Barracuda 7200.10)。退一步说,增长50%不算过份,450GB也不是个小数目。要知道,自从ATA硬盘驱动器的容量超过高转速(10K/15K RPM)的企业级硬盘驱动器以来,后者的重心就放在了IOPS(I/O per second,每秒I/O操作次数)性能上。随着15000RPM转速的成熟,10000RPM的IOPS不够高,容量却搞得那么大,似乎有些不伦不类。当然,减少盘片的数量可以缓解硬盘驱动器容量的增长,但是……好处在哪里?又不能降低硬盘的厚度,还不如缩小盘片的直径——这就引出了另一个因素,下一页将会详细讨论。
400GB、SAS接口的Cheetah NS,型号为ST3400755SS
从3.5英寸转向2.5英寸肯定是大势所趋,问题在于时间点。用户好像没有厂商所期待的那样乐观,他们仍然需要容量、性能与经济性相对平衡的3.5英寸10000RPM硬盘驱动器,于是Cheetah 10K.7、MAW系列和Ultrastar 15K300至今仍在各自东家主页的“Products”页面上,而同时代的Cheetah 15K.4及Savvio 10K.1却早已进了“Discontinued”名单。不过上述产品只能提供300GB以内的容量,未必能满足用户的胃口。幸亏希捷在宣布“Cheetah 10K.7是Cheetah 10K系列的最后一代产品,以后将不再发展万转的3.5英寸硬盘,以2.5英寸规格代替,Cheetah家族将只有15K RPM的转速”时,也没有把话说死,而是留下了“最终取决于用户需求”的活口。现在戴尔(Dell)这样的大客户说了“我要”,而且是更大的,怎么办?那就设法提供呗。
既然Cheetah 10K.7仍能很好地覆盖300GB以下的主流市场,只为一两个大容量点而设计一款全新的产品就未免有些不划算。于是,在Bill Watkins出任CEO之后已深谙“共用平台”之道的希捷做出了一个乍看起来不太容易令人相信的决定——将Cheetah 15K.5的转速从15000RPM降至10000RPM,推出容量为300GB和400GB的Cheetah NS!
Cheetah NS(右)和Cheetah 15K.5(左)看起来就像是从一个模子里刻出来的
Cheetah 15K.5单碟容量为75GB,将转速降低三分之一后,提升至100GB相对要容易许多,何况PMR技术又经过了一年的发展。与全新设计的做法相比,开发成本大为降低,对马达的要求亦可放宽,因此Cheetah NS的身价不致因脱胎于15000RPM硬盘驱动器而“水涨船高”,况且其面对的大容量市场也具有足够的承受力。由于Cheetah NS不是用来取代Cheetah 10K.7,两者之间是共存互补的关系,所以没有用Cheetah 10K.8的名字,从逻辑上是可以说得通的。
Cheetah NS(中)和Cheetah 15K.5的PCBA几乎完全相同,在布局风格上与Cheetah 10K.7(左)一脉相承
Cheetah NS支持4Gb/s FC-AL,400GB的容量还提供了3Gb/s SAS的选择,Ultra320 SCSI则彻底被抛弃。“高度整合(共用)Cheetah 15K.5之技术”(希捷语)的出身意味着Cheetah NS的盘片直径为2.75英寸(约69毫米),比通常的10000RPM硬盘驱动器要小近六分之一,这给它带来了两大优势:首先是寻道行程缩短,使平均寻道时间比Cheetah 10K.7缩短1毫秒左右,幅度接近20%;其次是功耗降低,标称值不到13瓦,希捷宣称“较其他3.5英寸10K/15K企业硬盘低28%”。在本文第一页的对比表中,也可以看到四碟SAS接口的Cheetah NS典型操作状态下的功耗指标仅比单碟80针SCA-2接口的Cheetah 10K.7稍高。
作为容量最大的10000RPM硬盘驱动器,Cheetah NS在性能上也有不错的表现,持续传输能力比Cheetah 10K.7高出50%
盘片直径缩小,单碟容量更大,意味着Cheetah NS的存储面密度(areal density)比Cheetah 10K.7有了很大的提高(毕竟相隔三年之久),体现在持续传输率上就是接近50%的增长,达到了外圈105MB/s、内圈60MB/s的水平。Cheetah 10K.7的突发速率与其Ultra320的前辈们一样超过了240MB/s,而Cheetah NS连200MB/s都没达到则略有些出人意料。
Cheetah NS与10K.1在IOPS性能上的差距是越拉越大
可以说,除了转速不同,Cheetah NS在很多方面都与Cheetah 15K.5保持一致,包括约69毫米的盘片直径和128深度队列支持。考虑到Cheetah 10K.7的盘片直径在80毫米的级别,Cheetah NS的平均寻道时间仅为其八成左右是很合理的,不过,HDTach的随机访问时间显示的差距只有0.5毫秒(7.5毫秒和8.0毫秒),明显小于0.8毫秒的理论值计算结果。无论如何,更短的平均访问时间和已走向成熟的SAS接口令Cheetah NS的IOPS性能占尽优势,在IOMeter的随机读测试中,当并发访问数达到64之后,其超出Cheetah 10K.7的幅度竟然高居40%!




本文转自 Gelada 51CTO博客,原文链接:http://blog.51cto.com/gelada/155692,如需转载请自行联系原作者
目录
相关文章
|
4月前
|
Android开发
Android编译出现Warning: Mapping new ns to old ns的解决方案
Android编译出现Warning: Mapping new ns to old ns的解决方案
354 3
|
存储 Java 开发工具
Warning: Mapping new ns http://schemas.android.com/repository/android/common/02 to old ns http://sch
构建警告:将新 ns 映射到旧 ns 尝试删除并重新安装 SDK 平台。删除 ~\Android\Sdk\platforms 中的文件夹并下载您需要的 SDK。 编辑:以上以某种方式解决了之前的问题,但是当更新更多外部包时,我再次遇到了同样的问题。这一次,删除 SDK 平台不起作用。相反,我在项目的两个位置更新了 Gradle:
2113 0
|
Swift iOS开发
Xcode10 NS_ASSUME_NONNULL_BEGIN NS_ASSUME_NONNULL_END
前言 升级成 Xcode 10 之后每次 New File 看到 .h 基本都能看到 NS_ASSUME_NONNULL_BEGIN 和 NS_ASSUME_NONNULL_END 成对出现在 @interface 与 @end 上下, 包裹住它, 这两对关键字并非新特性, 只是 Xcode 10 之后系统默认实现了, 应该是考虑到与 Swift 混编, 为了更好兼容其 optional 与 non-optional。
1846 0
查看域名服务器命令: $ dig -t NS xvideos.com
$ dig -t NS xvideos.com ; DiG 9.8.3-P1 -t NS xvideos.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER
4860 0