page cache 正在提高性能，因此您不想绕过它（或内核中的文件系统和其他层）。顺便说一句，您认为dd 会绕过它们是错误的（您可以通过strace(1) 一些dd 命令来检查），因为dd 正在使用（就像您的应用程序一样）system calls（在syscalls(2) 中列出） )
您可以阅读Advanced Linux Programming 和Operating Systems : Three Easy Pieces（两者均可免费下载）以了解更多信息。
顺便说一句，在创建文件系统时（例如 mkefs），您可以调整块大小等参数（例如 -b 选项到 mke2fs(8)...）；也许您可能会使用更大的块大小重新创建文件系统（但这并不重要）。
您可以将一个磁盘分区专用于您的应用程序（但您可能不应该）。请参阅 raw(8) - 可能已弃用 - 和 sd(4)。然后格式化您的磁盘并访问例如/dev/sdb3 作为代码中的块设备。但同样，这通常是不明智的。
请注意，如今的应用程序很少使用原始磁盘分区。例如，考虑 RDBMS，例如 PostGreSQL 或 MySQL。在 1980 年代，他们通常使用原始磁盘分区，而今天他们使用大型磁盘文件（因此文件开销无关紧要）并日常管理数 TB 的数据集。
如果您关心性能，我建议改用大缓冲区（例如，兆字节或其中一些，而不是千字节）来进行 read(2) 和 write(2) 操作，也许使用 posix_fadvise(2)（甚至readahead(2)) 系统调用。使用O_DIRECT 到open(2)（在Maxim's answer 中提到）会绕过页面缓存，因此可能会减慢速度（即使在某些情况下它可能会稍微加快速度）。另请参阅fsync(2)。在某些（但不是全部）情况下，使用mmap(2) 通过内存映射访问文件可能很有用。进行基准测试以找出适合您的特定应用程序和计算机（包括硬件）的缓冲区大小。
但你不会得到奇迹：瓶颈可能是磁盘硬件本身（而不是文件系统或任何其他软件层）。如果可能，请购买更多 RAM（以获得更好的 page cache）并获得更快的 SSD。
也许（或可能）您应该考虑使用 RDBMS（PosGresSQL、MySQL）或非 SQL DBMS（MongoDb、....）或像 Sqlite 或 GDBM 这样的库。它们经过良好调整并支持许多 TB。
对于庞大的数据集（PB 级），您可能会重新设计您的应用程序，购买/使用/开发专门的硬件和软件并聘请专家（但您不会在这里询问）。对于大型内容（TB），使用文件是明智之举，如今几 TB 的大文件都得到了很好的管理。如果你有很多 - 例如数百万个文件（每个文件都很小），您可能希望将它们组织在目录树中（例如，相当长的路径，如 dir01/subdir234/file4566）；如果可能，请避免使用巨大的目录（例如数千个文件）。我认为没有理由需要连续的磁盘块，因为今天的文件系统管理得很好。
顺便说一句，在当前的磁盘硬件（包括旋转和 SSD）上，“连续”块的意义不大......
还可以从与您的类似的free software 应用程序的现有代码中寻找灵感。
注意。我猜你所说的“大文件”是指可以保存在单个磁盘上的东西（最多只有几 TB）。
我需要存储的所有文件都是 100MB ~ 1GB。
这些实际上是非常小的（或至少是中等大小的）文件，它们很可能完全位于 RAM 中（在页面缓存中，另请参见 http://linuxatemyram.com/ ...）。所以你真的不应该打扰，当然你最好将它们作为普通文件保存在一些普通的文件系统中（实际上不需要调整任何东西）。
我只需将它们存储到/dev/sd[bcd...] 并记住它们的存储位置以备阅读。
您似乎想绕过文件系统，使用一些原始磁盘分区，并在您的用户级代码中痛苦地模仿文件系统的角色。简而言之，不要这样做（请记住，文件系统在内核中经过精心设计和调整系统代码；仅几个月的工作就不会做得那么好）。它甚至可能更糟（因为您不会像系统那样有效地使用页面缓存）。将您的数据作为普通文件保存在普通文件系统中。
（人生苦短，不要重复造轮子！）。
我正在制作一个包含 16 个以上 HDD 的小型简单存储系统。
也许你想要一个LVM 和/或一些RAID。我很惊讶你提到一个超过 16 个磁盘的小东西（也许购买更少但更大的磁盘可能会更好）。顺便说一句，16 个磁盘来保存几十个几千兆字节的文件确实是大材小用（因为它适合 一个 TB 磁盘）。不要忘记拥有足够的内存！并且不要忘记备份！
请记住，CPU 的数量faster 是磁盘（甚至是 SSD）的数千倍。所以几乎总是文件系统软件层开销根本不重要。可能您的代码受 I/O 限制，而不是 CPU 限制，因此针对 CPU 优化您的代码是没有用的（但是，调整缓冲区大小等......是值得的，但您应该进行基准测试）。
附注很遗憾，您问several 与同一任务相关的问题，但没有提供足够的上下文、动机和详细信息（数据量和带宽、什么计算机、什么样的应用程序和代码、什么领域和工业等...）。我敢肯定，有了更好更详细的问题——只要有这个答案——你就会得到更好、更有用的答案。