Created attachment 10658 [details]
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.
Attached patch is created after recent FreeBSD ZFS changes:
It is possible that ZOL returns EOPNOTSUPP in this case but I have no opportunity to test it:
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.
(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:
The master branch has been updated by Cary Coutant <firstname.lastname@example.org>:
Author: Cary Coutant <email@example.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 <firstname.lastname@example.org>
Cary Coutant <email@example.com>
* output.cc (gold_fallocate): Trivial return for len == 0.
Add fallback options when posix_fallocate and fallocate return
Fixed on trunk.