Bug 22540 - Gold fails when output file is lying on ZFS
Summary: Gold fails when output file is lying on ZFS
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Cary Coutant
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-02 11:02 UTC by Vladimir Kondratyev
Modified: 2017-12-02 17:59 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
gold-output.cc.patch (363 bytes, text/x-c++src)
2017-12-02 11:02 UTC, Vladimir Kondratyev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Kondratyev 2017-12-02 11:02:48 UTC
Created attachment 10658 [details]
gold-output.cc.patch

Some Copy-On-Write filesystems like recent ZFS does not support posix_fallocate as  it cannot provide guarantee that overwrites would never fail due to the lack
 of free space. In that case EINVAL is used to report that the underlying file system does not support the operation (POSIX.1-2008) that breaks gold if output file is lying on such a filesystem.
Fix gold with falling back to ftruncate(2) if posix_fallocate(2) returned EINVAL but correct offset and len parameters was passed.
Comment 1 Vladimir Kondratyev 2017-12-02 11:21:46 UTC
Attached patch is created after recent FreeBSD ZFS changes:
https://lists.freebsd.org/pipermail/svn-src-head/2017-November/105709.html

It is possible that ZOL returns EOPNOTSUPP in this case but I have no opportunity to test it: 
https://github.com/zfsonlinux/zfs/blob/master/module/zfs/zpl_file.c#L662
Comment 2 Cary Coutant 2017-12-02 15:52:57 UTC
Why the check for valid offset and length? Gold always passes 0 for offset and a positive value for length (if not, that's a bug, I think).

Also, I'd think we should also fall through if either posix_fallocate or fallocate returns EINVAL, ENOSYS, or EOPNOTSUPP.
Comment 3 Vladimir Kondratyev 2017-12-02 16:25:06 UTC
(In reply to Cary Coutant from comment #2)
> Why the check for valid offset and length? Gold always passes 0 for offset
> and a positive value for length (if not, that's a bug, I think).
If so those checks might be removed or converted to asserts.

> Also, I'd think we should also fall through if either posix_fallocate or
> fallocate returns EINVAL, ENOSYS, or EOPNOTSUPP.
Sounds reasonable. lld from FreeBSD LLVM does that already:
https://lists.freebsd.org/pipermail/svn-src-head/2017-November/105832.html
Comment 4 cvs-commit@gcc.gnu.org 2017-12-02 17:57:36 UTC
The master branch has been updated by Cary Coutant <ccoutant@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=222b39c283e3fd7823ad95ccc58ae94e76b63237

commit 222b39c283e3fd7823ad95ccc58ae94e76b63237
Author: Cary Coutant <ccoutant@gmail.com>
Date:   Sat Dec 2 09:56:40 2017 -0800

    Handle case where posix_fallocate is not supported for a filesystem.
    
    2017-12-02  Vladimir Kondratyev  <vladimir@kondratyev.su>
    	    Cary Coutant  <ccoutant@gmail.com>
    
    gold/
    	PR gold/22540
    	* output.cc (gold_fallocate): Trivial return for len == 0.
    	Add fallback options when posix_fallocate and fallocate return
    	not-supported errors.
Comment 5 Cary Coutant 2017-12-02 17:59:19 UTC
Fixed on trunk.