<div dir="ltr">But that would disable mmap IO on systems that don't support fallocate. I'm not sure if OpenBSD people are for example happy about that.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 30, 2017 at 2:03 PM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> If your system does not support fallocate(2), we use ftruncate(2) to create<br>
> an output file. fallocate(2) succeeds even if your disk have less space<br>
> than the requested size, because it creates a sparse file. If you mmap such<br>
> sparse file, you'll receive a SIGBUS when the disk actually becomes full.<br>
><br>
> So, lld can die suddenly with SIGBUS when your disk becomes full, and<br>
> currently we are not doing anything about it. It's sometimes hard to notice<br>
> that that was caused by the lack of disk space.<br>
><br>
> I wonder if we should print out a hint (e.g. "Bus error -- disk full?")<br>
> when we receive a SIGBUS. Any opinions?<br>
<br>
</div></div>I think we should change the llvm implementation of resize_file to fail<br>
if it cannot allocate the space. That is, it should only use ftruncate<br>
on OS X where apparently HFS allocates space with it.<br>
<br>
If resize_file fails than lld can fail gracefully or use annonymous<br>
memory and a plain write instead of mmap for producing the output.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>