Weirdly the same thing happens with upstream qemu (also compiled on RHEL 7).

$ ./qemu-img create -f qcow2 -o preallocation=falloc disk.img 262144
Formatting 'disk.img', fmt=qcow2 size=262144 encryption=off cluster_size=65536 preallocation=falloc lazy_refcounts=off refcount_bits=16
qemu-img: disk.img: Could not preallocate data for the new file: Bad file descriptor
$ ./qemu-img --version
qemu-img version 2.4.50, Copyright (c) 2004-2008 Fabrice Bellard

Could be a kernel thing I guess?

stat("disk.img", {st_mode=S_IFREG|0644, st_size=524288, ...}) = 0
open("disk.img", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0644) = 8
ftruncate(8, 524288)                    = 0
fallocate(8, 0, 0, 524288)              = -1 EOPNOTSUPP (Operation not supported)
fstat(8, {st_mode=S_IFREG|0644, st_size=524288, ...}) = 0
fstatfs(8, {f_type="NFS_SUPER_MAGIC", f_bsize=1048576, f_blocks=100666, f_bfree=57908, f_bavail=52772, f_files=6553600, f_ffree=5574214, f_fsid={0, 0}, f_namelen=255, f_frsize=1048576}) = 0
pread(8, 0x7fcd2ce9ac80, 1, 524287)     = -1 EBADF (Bad file descriptor)
close(8)                                = 0
write(2, "qemu-img:", 9qemu-img:)                = 9
write(2, " ", 1 )                        = 1
write(2, "disk.img: Could not preallocate "..., 74disk.img: Could not preallocate data for the new file: Bad file descriptor) = 74

Created attachment 1075791 [details]
bz1265196.c

Reproducer.  Simply compile this program and run it on an NFS
mounted filesystem.

$ gcc -Wall bz1265196.c -o bz1265196
$ ./bz1265196 
posix_fallocate failed: Bad file descriptor

On a regular filesystem there is no error.

kernel-3.10.0-306.0.1.el7.x86_64
glibc-2.17-105.el7.x86_64

Also happens in RHEL 7.1:

kernel-3.10.0-229.el7.x86_64
glibc-2.17-78.el7.x86_64

Therefore it's NOT a regression.

(In reply to Richard W.M. Jones from comment #3)
> Created attachment 1075791 [details]
> bz1265196.c
> 
> Reproducer.  Simply compile this program and run it on an NFS
> mounted filesystem.
> 
> $ gcc -Wall bz1265196.c -o bz1265196
> $ ./bz1265196 
> posix_fallocate failed: Bad file descriptor
> 
> On a regular filesystem there is no error.

The strace shows that fallocate() is actually returning EOPNOTSUPP, which looks correct to me (the version of NFS we're mounting with does not support fallocate).

Then the strace shows the test attempting a pread, which returns EBADF.  That is also correct, since the file was open O_WRONLY.

So apparently posix_fallocate is returning with the error set to EBADF.  I suspect it should be returning EOPNOTSUPP?  That looks like a bug in the posix_fallocate implementation to me; changing component to glibc in hopes glibc folks can shed some light.

I see now this is also a problem with upstream glibc.

The cause seems to be:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/posix_fallocate64.c;h=fb2dac6e1341938034b7a3ea09d4409d0f26aab1;hb=HEAD#l107

Also note that NFS versions since 4.2 have fallocate support.  That fallocate support is available in RHEL7.2 (see https://bugzilla.redhat.com/show_bug.cgi?id=1079385), but NFSv4.2 is not the default, so EOPNOTSUPP will continue to be the default behavior.

Please see the manual:
http://www.gnu.org/software/libc/manual/html_node/Storage-Allocation.html#index-posix_005ffallocate64

I have just committed a change to the manual to clarify that O_WRONLY files are not supported either:
https://www.sourceware.org/ml/libc-alpha/2015-09/msg00729.html

Unfortunately this is exactly as desgiend, there is little room to engineer a better solution, particularly for O_WRONLY which won't allow an atomic-CAS/SIGBUS solution for emulation.

You must open the file read/write for posix_fallocate emulation to work on filesystems that have no native fallocate support, or you must use linux fallocate directly to do the work (as described in the manual).

I'm open to other ideas.

Does this answer your questions?

(In reply to Carlos O'Donell from comment #9)
> Please see the manual:
> http://www.gnu.org/software/libc/manual/html_node/Storage-Allocation.
> html#index-posix_005ffallocate64
> 
> I have just committed a change to the manual to clarify that O_WRONLY files
> are not supported either:
> https://www.sourceware.org/ml/libc-alpha/2015-09/msg00729.html

That looks helpful, thanks!

Unfortunately I didn't think to check that manual.  At least on Fedora 22 the posix_fallocate man page is missing these details.

> Unfortunately this is exactly as desgiend, there is little room to engineer
> a better solution, particularly for O_WRONLY which won't allow an
> atomic-CAS/SIGBUS solution for emulation.

Understood.

> You must open the file read/write for posix_fallocate emulation to work on
> filesystems that have no native fallocate support, or you must use linux
> fallocate directly to do the work (as described in the manual).
> 
> I'm open to other ideas.
> 
> Does this answer your questions?

Sounds like this should be closed (NOTABUG?).

Just hold on with this bug.  I posted a patch to qemu-devel (not
available on the web page yet).

Created attachment 1078604 [details]
0001-block-raw-posix-Open-file-descriptor-O_RDWR-to-work-.patch

Kevin took my patch to qemu which changes the open flag from O_WRONLY
to O_RDWR.  So from the qemu point of view this is fixed.

Since qemu-devel is still broken, I have attached the patch which
was accepted to qemu here.

It'd be kind of nice to have this fix in RHEL since it affects the
'virt-v2v -oa preallocated' option.  So I'm going to change the
component of this bug back to qemu.

This is upstream commit 73ba05d9.

As this is not a 7.2 blocker, I'm waiting for the 7.3 tree to open before I can
backport it.

This was already fixed in qemu-kvm-rhev by a rebase.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html