On 28.10.19 10:30, Max Reitz wrote: > On 28.10.19 10:24, Max Reitz wrote: >> On 27.10.19 13:35, Stefan Hajnoczi wrote: >>> On Fri, Oct 25, 2019 at 11:58:46AM +0200, Max Reitz wrote: >>>> As for how we can address the issue, I see three ways: >>>> (1) The one presented in this series: On XFS with aio=native, we extend >>>> tracked requests for post-EOF fallocate() calls (i.e., write-zero >>>> operations) to reach until infinity (INT64_MAX in practice), mark >>>> them serializing and wait for other conflicting requests. >>>> >>>> Advantages: >>>> + Limits the impact to very specific cases >>>> (And that means it wouldn’t hurt too much to keep this workaround >>>> even when the XFS driver has been fixed) >>>> + Works around the bug where it happens, namely in file-posix >>>> >>>> Disadvantages: >>>> - A bit complex >>>> - A bit of a layering violation (should file-posix have access to >>>> tracked requests?) >>> >>> Your patch series is reasonable. I don't think it's too bad. >>> >>> The main question is how to detect the XFS fix once it ships. XFS >>> already has a ton of ioctls, so maybe they don't mind adding a >>> feature/quirk bit map ioctl for publishing information about bug fixes >>> to userspace. I didn't see another obvious way of doing it, maybe a >>> mount option that the kernel automatically sets and that gets reported >>> to userspace? >> >> I’ll add a note to the RH BZ. >> >>> If we imagine that XFS will not provide a mechanism to detect the >>> presence of the fix, then could we ask QEMU package maintainers to >>> ./configure --disable-xfs-fallocate-beyond-eof-workaround at some point >>> in the future when their distro has been shipping a fixed kernel for a >>> while? It's ugly because it doesn't work if the user installs an older >>> custom-built kernel on the host. But at least it will cover 98% of >>> users... >> >> :-/ >> >> I don’t like it, but I suppose it would work. We could also >> automatically enable this disabling option in configure when we detect >> uname to report a kernel version that must include the fix. (This >> wouldn’t work for kernel with backported fixes, but those disappear over >> time...) > I just realized that none of this is going to work for the gluster case > brought up by Nir. The affected kernel is the remote one and we have no > insight into that. I don’t think we can do ioctls to XFS over gluster, > can we?
On third thought, we could try to detect whether the file is on a remote filesystem, and if so enable the workaround unconditionally. I suppose it wouldn’t hurt performance-wise, given that it’s a remote filesystem anyway. Max
signature.asc
Description: OpenPGP digital signature
