声明16GB的BSS段存储海量文件名是否存在技术弊端？

我正在开发一款内存用量不可预测的程序：它处理的目录可能只包含少量文件，也可能有数千万个文件。受内核行为限制，必须一次性将所有文件名存入RAM。

下面这段代码并非我的程序，仅用于说明必须一次性存储文件名的原因：

DIR *dir = opendir(".");
for (struct dirent *entry; (entry = readdir(dir);)
    unlink(entry->d_name); // DANGER DO NOT RUN ME

这段代码看似会删除当前目录下的所有文件，但实际会因目录树条目变更破坏枚举稳定性，导致遗漏部分文件。

该程序的几乎所有内存都需要用于存储全部文件名的单一缓冲区，我设计了如下内存结构（ASLR已开启，0为虚拟起始地址，非实际物理地址）：

000000000 ELF header
000000118 Program code
000001000 work buffers
000002000 begin stretchy array
400002000 no man's land (mapped with 0 access so anything hitting it faults)
400003000 top of stack
400005000 bottom of stack

无需讨论代码或栈空间过小的问题，相关常量可轻松调整。

我需要讨论的是大型动态数组的实现：管理非连续数组会产生冗余开销，而MMU允许虚拟地址空间无需物理内存连续。我曾在单用户系统中见过这种技巧，但不确定在多用户主机上是否会出现问题。

我的需求是内存仅在被访问时才分配，此前不占用物理资源。那么，声明一个16GB大小的BSS段但仅使用实际所需部分的做法存在哪些风险？由于该段过大，必须确保栈不会与其冲突，因此使用mmap()动态分配地址空间的方案不可行。

我还考虑过另一种方案：如果PE格式支持，可在启动时预留内存并按需通过mmap提交，但手册显示mmap无法预留16GB地址空间且不实际分配物理内存。

目前我已编写了一个包含空程序（mov al, 60 ; syscall）的ELF头，程序可正常运行，现咨询该方案的技术弊端。

内容的提问来源于stack exchange，提问作者Joshua