<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 23, 2017 at 3:40 PM, Brian Cain <span dir="ltr"><<a href="mailto:brian.cain@gmail.com" target="_blank">brian.cain@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Mon, Oct 23, 2017 at 5:21 PM, Rui Ueyama via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If your system does not support fallocate(2), we use ftruncate(2) to create an output file. fallocate(2) succeeds even if your disk have less space than the requested size, because it creates a sparse file. If you mmap such sparse file, you'll receive a SIGBUS when the disk actually becomes full.<div><br></div><div>So, lld can die suddenly with SIGBUS when your disk becomes full, and currently we are not doing anything about it. It's sometimes hard to notice that that was caused by the lack of disk space.</div><div><br></div><div>I wonder if we should print out a hint (e.g. "Bus error -- disk full?") when we receive a SIGBUS. Any opinions?</div></div>
<br></blockquote><div><br></div></div></div><div>What about reading back the file's size with stat() before mapping? .st_blocks should give the "real" size.</div></div></div></div></blockquote><div><br></div><div>Creating a sparse file is not an error, and a sparse file works fine as long as your disk has enough space (which is almost always true.) So I don't know how stat helps.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>BTW, posix_fallocate() might provide better portability and decrease the likelihood of falling back on ftruncate().</div></div></div></div></blockquote><div><br></div><div>Yes, but we want to avoid that function because when it falls back, it is very slow. What it does when fallocate(2) is not available is to actually write 0 to every block to make sure that all disk blocks are allocated. Doing it every time the linker creates a new file is a bit overkill to guard against disk full situation which isn't common.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><span class="gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_1290078694163631811gmail_signature">-Brian</div>
</font></span></div></div>
</blockquote></div><br></div></div>