简体   繁体   English

FreeBSD ftruncate()+mmap() 大洞警告

[英]FreeBSD ftruncate()+mmap() big hole warning

FreeBSD 13.1 manual page mmap() has the following warning: FreeBSD 13.1 手册页mmap()有以下警告:

WARNING, Extending a file with ftruncate(2), thus creating a big hole.警告,使用 ftruncate(2) 扩展文件,从而创建一个大洞。 and then filling the hole by modifying a shared mmap() can lead to severe file fragmentation.然后通过修改共享的 mmap() 来填补漏洞会导致严重的文件碎片。 In order to avoid such fragmentation you should always pre-allocate the file's backing store by write()ing zero's into the newly extended area prior to modifying the area via your mmap(), The fragmentation problem is especially sensitive to MAP_NOSYNC pages.为了避免这种碎片,在通过 mmap() 修改区域之前,您应该始终通过将零写入新扩展区域来预先分配文件的后备存储,碎片问题对 MAP_NOSYNC 页面特别敏感。 because pages may be flushed to disk in a totally random order.因为页面可能以完全随机的顺序刷新到磁盘。

Questions:问题:

  1. What is this big hole;这个大洞是什么? why ftruncate() has the effect of creating it;为什么ftruncate()具有创建它的效果; and why write() is a proposed solution to the problem?为什么write()是该问题的建议解决方案?
  2. How does one efficiently zero-fill the hole after ftruncate() and before mmap() ?如何在ftruncate()之后和mmap()之前有效地零填充孔? Repeatedly calling write() sounds like more system calls that maybe necessary.重复调用write()听起来可能需要更多的系统调用。
  3. Does the same problem exist on other operating systems?其他操作系统是否存在同样的问题? I find no such warning on macOS or Linux.我在 macOS 或 Linux 上没有发现这样的警告。

You can avoid this problem by using posix_fallocate to preallocate desired areas.您可以通过使用posix_fallocate预分配所需区域来避免此问题。

The hole is created because files can be sparse, taking up only the space required for the actually used areas, so when using just ftruncate , the backing for the new area is virtual, it isn't reserved on disk until you allocate it or write to it.创建这个洞是因为文件可能很稀疏,只占用实际使用的区域所需的空间,所以当只使用ftruncate时,新区域的支持是虚拟的,它不会保留在磁盘上,直到你分配它或写入给它。

It applies to Linux as well, it's just not mentioned.它也适用于 Linux,只是没有提到。 You can expect most filesystem implementations to do similarly;您可以期望大多数文件系统实现都做类似的事情; often they do try to be smart, and will defragment your writes if time-wise close one to another, but can't do magic.通常他们确实会尝试变得聪明,并且如果在时间上彼此接近,则会对您的写入进行碎片整理,但无法发挥作用。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM