一位相当权威的EMC博主与IBM展开了激烈争论，其核心议题在于谁才是足以与蓝色巨人的TSM备份与归档软件相匹配的最佳向外扩展后端存储库：EMC的Isilon还是蓝色巨人的GPFS。
IBM方面表示，其TSM——即Tivoli存储管理器——产品“提供备份、归档、恢复、空间管理、数据库与应用程序保护以及裸机恢复与灾难恢复功能。
Stefan Radtke则在自己的博客中指出，“Isilon是最适合与TSM备份相匹配的完美解决方案。”
他表示自己是通过客户实际部署得出这个结论的，初始TSM实例数量为4个、运行在Windows 2012之上，所有备份内容由两台18TB NetApp阵列与两套TS3500磁带库负责——每个磁带库配备八个LTO4驱动器——并构成SAN体系。
这套方案随后进行了调整，TSM实例数量保持不变，但备份内容由具备432TB原始容量（可用容量为260TiB）的3节点LAN连接Isilon NL400集群与一套配备8个LTO4驱动器的TS3500磁带库负责打理。
Radtke的TSM与Isilon配置方案。
对于NetApp配置方案，Radtke指出：“备份、归档与迁移任务以100MB到150MB每秒的速度彻底进行，有时甚至会持续到中午……而归档任务……每天的执行时长则在八到十六个小时之间。”
在切换至Isilon之后，就单一TSM实例来看：“数据吞吐能力提升到约400MB每秒……归档数据吞吐能力……外加备份与恢复数据吞吐能力……也获得了改进，其执行完成时间比原先提前了数个小时。”
在对TSM进行调整以使用更多线程之后，“数据吞吐能力进一步增加至800MB每秒，而归档数据吞吐能力也提升到150MB每秒与750MB每秒之间，运行时长则由原本的16小时缩短至约2.5小时。”
由于大部分数据都被保存在Isilon阵列当中，因此现在只需要一套磁带库与之相搭配。
Radtke对于Isilon的表现作出如下总结：
- 备份与归档的平均数据吞吐能力已经提高至原本的约五倍。
- 运行时间也获得了同样程度的缩减（由12小时降低至2.5小时）。
- 由于所有TSM服务器都共享同一套文件系统，因此其复杂程度得以大大降低。
- TSM服务器与Isilon之间不再存在SAN组件（因此不必再为分卷、LUN掩蔽、SAN分区以及设备类定义变化等麻烦事操心）。
- 恢复速度总体而言也变得更快。
在另一方面，IBM、Andre Gaschler与Nils Haustein则探讨了在GPFS存储方案之上运行TSM服务器的实际效果。
他们解释称，GPFS利用“经过优化的高性能集群文件系统为应用程序带来指向单一集群中多个节点的并发高速文件访问机制。”
这二位“进行了一系列将TSM与IBM System x GPFS存储服务器（简称GSS）相结合的测试工作。这套GSS系统提供标准GPFS文件系统，其配置在GPFS本地RAID设备（简称GNR）之上。 TSM服务器软件运行所在的服务器则利用高速网络连接与GSS文件系统相对接。”GSS设备与两台TSM服务器之间的连接为56Gbit每秒 InfiniBand。
他们总结出了如下结论：
- 在单一TSM服务器上执行多个会话时的峰值备份性能为每秒5.4GB。
- 在两台TSM服务器上执行多个会话时的峰值备份性能为每服务器每秒4.5GB，合共每秒9GB。
- 在单一TSM服务器上执行多个会话时的峰值恢复性能为每秒6.5GB。
- 在单一TSM服务器上执行单一会话时的峰值恢复性能为每秒2.5GB。
他们指出：“这些性能指标明确证实，TSM服务器能够在GSS（即GPFS存储服务器）上获得线性性能扩展。”
这两位GPFS支持者总结道：“GSS将优秀性能表现与操作简化加以结合，为我们带来一套堪称完美的TSM存储环境。多TSM实例能够在基于GPFS的弹性存储云当中实现全方位向外扩展。”
TSM/Isilon组合的峰值数据吞吐能力为每秒800MB，相比之下TSM/GPFS的峰值数据吞吐能力则高达 5.4GB每秒（相当于每秒5400MB）——几乎达到前者的七倍。诚然，将二者直接加以对比并不准确，但这样的结果显然说明Isilon并不是惟一值得 认真考量的方案——GPFS同样具备出色甚至是更为出色的实际表现。