我希望能够在不调用任何 io 的情况下将文件内存映射的范围归零（以便有效地顺序覆盖大文件而不引起任何磁盘读取 io）。

std::memset(ptr, 0, length)如果页面尚未在内存中，即使整个页面都被覆盖，这样做也会导致从磁盘读取页面，从而完全破坏磁盘性能。

我希望能够执行类似的操作madvise(ptr, length, MADV_ZERO)，将范围归零（类似于FALLOC_FL_ZERO_RANGE），以便在访问指定范围时导致零填充页面错误而不是常规 io 页面错误。

可惜MADV_ZERO不存在。尽管相应的标志FALLOC_FL_ZERO_RANGE确实存在fallocate并且可以用于fwrite实现类似的效果，但没有即时的跨进程一致性。

我猜一种可能的选择是使用MADV_REMOVE. 但是，据我了解，这可能会导致文件碎片化，并且还会在完成时阻止其他操作，这使我不确定其长期性能影响。我对 Windows 的体验是，类似的FSCTL_SET_ZERO_DATA命令在调用时会导致显着的性能峰值。

我的问题是如何实现或模拟MADV_ZERO共享映射，最好是在用户模式下？

1./dev/zero/

我读过它被建议简单地读/dev/zero入选定的范围。虽然我不太确定“读入范围”是什么意思以及如何去做。它就像fread从/dev/zero内存范围内一样吗？不确定如何避免访问时出现常规页面错误？

对于 Linux，只需读取/dev/zero所选范围即可。内核已经针对匿名映射优化了这种情况。

如果通常这样做太难实现，我
建议 MADV_ZERO 应该有这样的效果：就像
将 /dev/zero 读入范围一样，但总是有效的。

编辑：进一步跟踪线程，事实证明它实际上不起作用。

当您处理共享映射时，它不会做任何技巧。

2.MADV_REMOVE

在 Linux 中实现它的一种猜测（即不在我更喜欢的用户应用程序中）可以通过简单地复制和修改来实现MADV_REMOVE，即madvise_remove使用FALLOC_FL_ZERO_RANGE而不是FALLOC_FL_PUNCH_HOLE. 虽然我在猜测这一点时有点过头了，特别是因为我不太明白周围的代码在vfs_allocate做什么：

考虑我有以下代码：

这是我为测试我的假设而制作的 /usr/bin/fallocate 的简单版本。我发现如果我使用它来创建一个大于文件系统可用空间的文件，它将返回 -1 和正确的 errno，但仍会创建一个最大允许大小的文件。这对我来说似乎很奇怪，因为该命令显式返回 -1，这应该是失败的信号，但它仍然做了一些事情。而且它没有我要求的 - 它创建了一个未知（在我运行它的那一刻）大小的文件。如果我使用 fallocate() 为我不知道的小猫照片保留一些空间，那么如果它保留的空间比我要求的少，那对我来说将毫无用处。

是的， fallocate() 和 posix_fallocate() 的行为是保存方式，如您所见，我检查了两者。

自然地，我认为我做错了什么。因为如果您在编程时遇到问题，99.9% 都会发生这种情况。所以我尝试了 /usr/bin/fallocate 实用程序，是的，它“失败”，但仍然创建一个文件。

这是我运行该实用程序的示例：

正如您所看到的，它在 fallocate() 调用中没有设置特定的模式，它失败了，但是文件被创建了，大小意外。

我发现互联网上的一些人看到了相反的行为：

（它用俄语说“没有足够的空间”）

我已经尝试了 ext4 和 tmpfs，结果相同。我有 gentoo linux，3.18 内核。但是最初我在最新的 SLES12 上看到了这个问题。

我的问题是：为什么会有不同的结果，我如何防止 /usr/bin/fallocate 或 fallocate() 创建文件以防万一

我有一行像dd if=/dev/zero of=myImg.img bs=1KB count=1024k，我必须在我的脚本中做几次。因此，我想将此行集成到我的 perl 脚本中，而不是通过system('...');调用，而是通过创建函数。有什么好的方法吗？

我已经用MakeMaker试过了，但我没有找到正确的方法来设置我的文件长度/偏移量，或者任何类似于-o -lfrom的东西fallocate。当然，显而易见的方法open(FH,">/myFolder/MyImg.img");也不起作用。

我正在查看fallocate的手册页，但我不明白这两者之间的区别。一种似乎分配了块但没有写入它们，另一种似乎释放了块而不覆盖它们。无论哪种方式，从用户的角度来看，效果似乎都无法区分。请给我解释一下。

清零文件空间在模式中指定 FALLOC_FL_ZERO_RANGE 标志（自 Linux 3.15 起可用）会将字节范围内的空间清零，从 offset 开始并持续到 len 个字节。在指定范围内，为跨越文件中空洞的区域预先分配块。成功调用后，从此范围内的后续读取将返回零。

增加文件空间 在模式中指定 FALLOC_FL_INSERT_RANGE 标志（自 Linux 4.1 起可用）通过在文件大小内插入一个洞而不覆盖任何现有数据来增加文件空间。该孔将从偏移量开始并持续 len 个字节。当在文件中插入孔时，从偏移量开始的文件内容将向上移动（即到更高的文件偏移量） len 个字节。在文件中插入一个洞会使文件大小增加 len 个字节。

最近，我正在测试 ext4 文件系统的正确用法。我的专家是：

当系统崩溃时，数据已经写入返回 ok 不会丢失，但 metadate 可以。
下面是我的用法：
1. 调用 fallocate 来分配 centain 空间 fallocate(fd, 0, 0, 4*1024*1024); //4MB
2. 调用 fsync(fd) 让数据和元数据写入磁盘
3. 然后我调用函数随机写入 4k 大小的文件（随机数据但不是 0）。带有 O_DRICT 标志，但不调用 fsync。我用 return write ok 记录偏移量。
4.检查记录的偏移量。但我发现在一些偏移量中，读取 4k 数据是 0。这似乎意味着偏移量不像孔文件那样使用。

我的问题是：
<1。为什么在调用 fallocate 和 fsync 后，文件的元数据似乎仍然表明某些块没有被使用，所以当读取它时返回 null。这是我的理解。
<2。有其他api可以调用，可以确保在分配文件空间时没有空洞，之后写入数据时返回ok，用O_DIRECT可以确保即使系统崩溃数据也不会丢失。

我需要分配大文件而不将其内容归零。我正在制作fopen => ftruncate => fclose => mmap => (...work...) => munmap具有巨大文件大小（数百 GB）的这些步骤。应用程序在系统尝试将文件字节归零时挂起几分钟 - 恕我直言，因为ftruncate使用。

似乎它不适用于注释行[1]。但是取消注释这一行会产生我试图避免的文件归零。在写之前我真的不在乎脏文件内容。我只是想避免挂在应用程序终止上。

解决方案：

根据@torfo的回答，用这几行替换了我所有与 Apple 相关的代码：

但仅适用于超级用户！

他们都可以根据我的测试更改文件大小。为什么他们都可以将文件更改为更大或更短？fallocate 和 ftruncate 有什么区别？

我的目标是立即为文件分配大量空间，而不会生成稀疏文件。从文件中读取应该输出剩余空间中的垃圾，而不是 0。

两者都truncate制作fallocate稀疏文件。

这可能吗？

我有一个将共享内存与内存映射文件一起使用的应用程序。目标操作系统是 Ubuntu 14.04（64 位）。此发行版上的 Linux 内核版本为 4.4.0。gcc 的版本为 4.8.4。

直到最近，我还在使用以下函数调用（按所示顺序）来分配和解除分配共享内存。

这种方法的问题是它不能检测是否有足够的内存可用于共享内存。SIGBUS当访问共享内存时，应用程序将在稍后的某个时间点崩溃并发出信号。

我发现人们在这里遇到了同样的问题，他们通过使用fallocate()而不是ftruncate(). fallocate()如果没有足够的内存可用于请求的大小，将返回错误。

我在我的应用程序中实现了相同的功能，并且fallocate()可以在没有足够内存时正确检测到这种情况但是，我现在遇到了另一个问题。

问题是调用后保留的内存fallocate()没有释放shm_unlink()。使用时这不是问题ftruncate()。

考虑以下fallocate.c展示此行为的最小示例 ( )。

我使用以下内容CMakeLists.txt进行编译

运行此示例gdb并在最后一条printf语句上中断。您将看到以下行为。

• 该test文件不再存在于/dev/shm
• 查看top输出时，内存仍处于“已使用”类别；一旦进程终止，它只会移动到“免费”类别

这是预期的行为还是我错误地使用了 API？

编辑：按要求处理之后的进程地址空间shm_unlink()（使用gets()aftershm_unlink()来保存进程）

的输出cat /proc/<PID>/status

的输出pmap <PID>

我正在尝试将一个 64M 文件映射到内存中，然后对其进行读写。但是有时这个文件中的某个范围将不再被使用，所以我打电话fallocate(fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 16 << 20, 16 << 20);释放它里面的一个 16M 范围。

但是，我发现内存消耗似乎没有改变（来自free -m和来自cat /proc/meminfo）。

我知道 fallocate 会在文件中挖一些洞，并将这些范围返回给文件系统。但我不确定它是否会减少映射文件的内存消耗。

如果它不减少内存消耗，那么这样的范围在哪里？另一个进程能否获得先前分配给它的底层内存？

big.file 是一个普通的 64M 文件而不是稀疏文件