小文件很多：此类文件用于存储原始或临时的基因组信息，如测序器输出(像Illumina公司的BCL格式文件)。它们通常小于64KB，可占典型基因组数据仓库文件数量一半以上。与处理大文件不同，因为每个文件的I/O都需要对数据和元数据进行两次操作，生成和访问大量文件的负载会非常大，如果按每秒操作数(IOPS)衡量速度，底层存储系统的IOPS可达数百万次。由此可以想到，对于AMRC在圣地亚哥的基础设施，未曾对小文件处理的存储做过任何优化，诸如BCL转换(像Illumina公司的CASAVA算法)这样的负载会因基础设施有限的I/O能力(尤其是IOPS)，导致计算资源枯竭而最终瘫痪。基准测试证实，因计算能力浪费在等待数据就位上，CPU效率会下降至个位数。为了缓解这种计算瓶颈，需要使用数据缓存技术将I/O操作从磁盘转移到内存。
并行和工作流操作：为提高性能、加快时间，基因组计算通常以编排好的工作流批量进行。从小范围目标测序到大范围全基因组测序，为使负载在快速运转中发挥更高效能，并行操作不可或缺。随着成百上千种不同的负载在并行计算环境中同时运行，以I/O带宽和IOPS衡量的存储速度将不断累积并爆发式增长。纽约AMRC的生物信息学应用可并发运行在2500个计算核心，以每秒写一个文件的速度创建百万级数据对象，无论是2500个目录、每个目录2500个文件，亦或是一个目录中的1400万个文件都能被及时处理。而对于一个拥有6亿对象、900万目录、每个目录仅含一个文件的数据仓库，这仅仅是其众多负载中的一小部分。由于元数据是海量的，IOPS负荷会约束整体性能，即使一个列出文件的系统命令(如Linux的ls)也不得不耗费几分钟的时间才能完成，并行应用程序如GATK队列也遭遇了这种低性能。2014年初，文件系统以改善元数据基础结构为着眼点进行了大幅修正，带宽和IOPS性能均得到显著改善，基准测试显示，在没有任何应用程序调整的情况下，基因疾病应用程序的计算加速了10倍。
数据多样性
按存储和访问方式，数据格式可有多种类型，如多步工作流生成的中间文件，亦或是一些输出文件，其中包含维持生命必需的基因组信息参考数据，而这些数据需要谨慎的进行版本控制。目前常规的方法是，不考虑费用，在一个存储层把所有数据在线或近线存储，这样做会导致大数据生命周期管理能力的缺失。如果基因组数据仓库要用很长时间扫描文件系统，迁移或备份就不可能及时被完成。一家美国大型基因组中心，在采用了Illumina公司的X10全基因组测序算法后，一直挣扎于如何管理快速增长的数据。目前他们完成整个文件系统的扫描需要四天，使得每日或更长一点时间的备份变得不可能。其结果是，数据在单层存储快速堆积，元数据扫描性能不断下降，导致数据管理恶性循环。