[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170612175520.GF1214367@wirbelwind>
Date: Mon, 12 Jun 2017 19:55:20 +0200
From: Joakim Sindholt <opensource@...sha.com>
To: musl@...ts.openwall.com, slade@...nam.net
Subject: Re: ENOSYS/EOPNOTSUPP fallback?
On Sun, Jun 11, 2017 at 02:57:59PM -0600, Benjamin Slade wrote:
> Thank you for the extensive reply.
>
> Just to be clear: I'm just an end-user of flatpak, &c. As far as I can
> tell, flatpak is making use of `ostree` which assumes that the libc will
> take care of handling `dd` fallback (I got the impression that flatpak
> isn't directly calling `fallocate` itself).
I don't think it's fair to say that they depend on the fallback. POSIX
is very clear that posix_fallocate doesn't fail in the way musl fails
here[1]. They (hopefully) expect it to behave as described in the
standard and there's not much musl can do to alleviate the problem.
> Do you think there's an obvious avenue for following up on this?
> Admittedly this is an edge-case that won't necessarily affect musl users
> on ext4, but it will affect musl users on zfs (and I believe
> f2fs). Do you think `ostree` shouldn't rely on the libc for fallback? Or
> should ZFS on Linux implement a fallback for fallocate?
The reason I recommended using fallocate in a way where failure is
non-fatal is that it's probably going to be a pain to fix it properly in
the kernel. After having a look at zfsonlinux[2] it's not at all clear
how much work it would be. Currently they only support calling
fallocate(2) with parameters to deallocate a section of a file because
that seems to have been the only low hanging fruit.
Ultimately, ostree isn't doing anything wrong by expecting it to work,
but it might not be something they depend on succeeding internally. In
which case the easy fix for your particular case is to just make the
failure non-fatal, which is probably really easy.
If you want to fix it properly the only option I can see is to fix it in
the driver. I don't think any userspace level hack is going to be
upstreamable in musl, as it would violate the standard in very bad ways
AND appear to work.
Most people here are really big on correctness and I think it would be
really cool to see it fixed in zfs :)
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
[2] https://github.com/zfsonlinux/zfs/commit/cb2d19010d8fbcf6c22585cd8763fad3ba7db724
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
