On 2017-Nov-4, at 10:02 AM, Mark Millard <markmi at dsl-only.net> wrote: > On 2017-Nov-4, at 4:58 AM, Ed Maste <emaste at freebsd.org> wrote: > >> On 4 November 2017 at 07:41, Andriy Gapon <avg at freebsd.org> wrote: >>> On 04/11/2017 12:32, Mark Millard wrote: >>>> if (int Err = ::posix_fallocate(FD, 0, Size)) { >>>> if (Err != EOPNOTSUPP) >>>> return std::error_code(Err, std::generic_category()); >>>> } >>> >>> The commit message that you didn't include into your reply contains some useful >>> information that authors / maintainers of this code should probably take into >>> account: >>> >>>> Please note that EINVAL is used to report that the underlying file system >>>> does not support the operation (POSIX.1-2008). >>> >>> Here is a link for that: >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html >> >> I have no idea how they decided EINVAL was a reasonable errno for this case. >> >> Mark, can you give this patch a try: >> >> diff --git a/contrib/llvm/lib/Support/Unix/Path.inc >> b/contrib/llvm/lib/Support/Unix/Path.inc >> index 45097eb918b7..67edb46f0025 100644 >> --- a/contrib/llvm/lib/Support/Unix/Path.inc >> +++ b/contrib/llvm/lib/Support/Unix/Path.inc >> _at__at_ -427,7 +427,7 _at__at_ std::error_code resize_file(int FD, uint64_t Size) { >> // If we have posix_fallocate use it. Unlike ftruncate it always allocates >> // space, so we get an error if the disk is full. >> if (int Err = ::posix_fallocate(FD, 0, Size)) { >> - if (Err != EOPNOTSUPP) >> + if (Err != EINVAL && Err != EOPNOTSUPP) >> return std::error_code(Err, std::generic_category()); > > I've got a simple buildworld going but I expect that > it will end up using lld in a form that runs into > the problem. But I may luck out since I can link a > trivial main to produce an a.out for amd64. Actually I take that back: I no longer have WITH_LLD_IS_LD= as part of my normal amd64 environment. (I did for a time.) So I will not get the problem. > It may be appropriate to have notes somewhere about > what to do for folks that land in the range -r325320 > to whatever revision the updated > contrib/llvm/lib/Support/Unix/Path.inc ends up at > and that also have a zfs filesystem context involved. Explicitly adding to that context-requirement for having the problem for amd64: and that one has WITH_LLD_IS_LD= in use. Of course, for arm64.aarch64 WITH_LLD_IS_LD= is the normal case and so would be more likely to catch folks. So this too should be explicit. > I'll let you know if the build completes vs. not. It > takes a while since llvm materials are rebuilding. It should complete since binutils's ld is in use: I'm not building on aarch64 and reverted to normal for amd64 some time ago relateive to WITH_LLD_IS_LD= . === Mark Millard markmi at dsl-only.netReceived on Sat Nov 04 2017 - 16:13:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC