Re: [GEDI] [PATCH 07/17] gluster: Drop useless has_zero_init callback

[Eric Blake <eblake@redhat.com>]

On 2/17/20 2:06 AM, Niels de Vos wrote:
> On Fri, Jan 31, 2020 at 11:44:26AM -0600, Eric Blake wrote:
>> block.c already defaults to 0 if we don't provide a callback; there's
>> no need to write a callback that always fails.
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
> 
> Reviewed-by: Niels de Vos <ndevos@redhat.com>
> 

Per your other message,

On 2/17/20 2:16 AM, Niels de Vos wrote:
 > On Fri, Jan 31, 2020 at 11:44:31AM -0600, Eric Blake wrote:
 >> Since gluster already copies file-posix for lseek usage in block
 >> status, it also makes sense to copy it for learning if the image
 >> currently reads as all zeroes.
 >>

 >> +static int qemu_gluster_known_zeroes(BlockDriverState *bs)
 >> +{
 >> +    /*
 >> +     * GlusterFS volume could be backed by a block device, with no way
 >
 > Actually, Gluster dropped support for volumes backed by block devices
 > (LVM) a few releases back. Nobody could be found that used it, and it
 > could not be combined with other Gluster features. All contents on a
 > Gluster volume is now always backed by 'normal' files on a filesystem.

That's useful to know.  Thanks!

 >
 > Creation or truncation should behave just as on a file on a local
 > filesystem. So maybe qemu_gluster_known_zeroes is not needed at all?

Which version of gluster first required a regular filesystem backing for 
all gluster files?  Does qemu support older versions (in which case, 
what is the correct version-probing invocation to return 0 prior to that 
point, and 1 after), or do all versions supported by qemu already 
guarantee zero initialization on creation or widening truncation by 
virtue of POSIX file semantics (in which case, patch 7 should instead 
switch to using .bdrv_has_zero_init_1 for both functions)?  Per 
configure, we probe for glusterfs_xlator_opt from gluster 4, which 
implies the code still tries to be portable to even older gluster, but 
I'm not sure if this squares with qemu-doc.texi which mentions our 
minimum distro policy (for example, now that qemu requires python 3 
consistent with our distro policy, that rules out several older systems 
where older gluster was likely to be present).

I'm respinning the series for other reasons, but would like to get this 
right as part of that respin.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org