[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [GEDI] [PATCH 07/17] gluster: Drop useless has_zero_init callback
Date: Mon, 17 Feb 2020 06:03:40 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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 <address@hidden>

Reviewed-by: Niels de Vos <address@hidden>

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]