llvm dev - Oct 2017 - lld: sigbus error handling

On Mon, Oct 23, 2017 at 3:40 PM, Brian Cain <brian.cain at gmail.com>
wrote:
>
>
> On Mon, Oct 23, 2017 at 5:21 PM, Rui Ueyama via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>> 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.
>>
>> I wonder if we should print out a hint (e.g. "Bus error -- disk
full?")
>> when we receive a SIGBUS. Any opinions?
>>
>>
> What about reading back the file's size with stat() before mapping?
> .st_blocks should give the "real" size.
>
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.

> BTW, posix_fallocate() might provide better portability and decrease the
> likelihood of falling back on ftruncate().
>
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.

>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
>
> --
> -Brian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171023/ea65dfca/attachment.html>

On 23 October 2017 at 18:49, Rui Ueyama via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>
>> BTW, posix_fallocate() might provide better portability and decrease
the
>> likelihood of falling back on ftruncate().
>
> 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.
Note that posix_fallocate may return EINVAL if the underlying
filesystem does not support the operation.

Does FreeBSD have fallocate(2) or equivalent?

On Mon, Oct 30, 2017 at 4:32 PM, Ed Maste <emaste at freebsd.org> wrote:
> On 23 October 2017 at 18:49, Rui Ueyama via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >>
> >> BTW, posix_fallocate() might provide better portability and
decrease the
> >> likelihood of falling back on ftruncate().
> >
> > 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.
>
> Note that posix_fallocate may return EINVAL if the underlying
> filesystem does not support the operation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171031/5c474aab/attachment.html>