Re: [Qemu-devel] [Qemu-block] [PATCH] block/gluster: add support for SEEK_DATA/SEEK_HOLE

[Kevin Wolf <kwolf@redhat.com>]

Am 08.03.2016 um 05:21 hat Niels de Vos geschrieben:
> On Mon, Mar 07, 2016 at 01:27:38PM -0500, Jeff Cody wrote:
> > On Mon, Mar 07, 2016 at 07:04:15PM +0100, Niels de Vos wrote:
> > > GlusterFS 3.8 contains support for SEEK_DATA and SEEK_HOLE. This makes
> > > it possible to detect sparse areas in files.
> > > 
> > > Signed-off-by: Niels de Vos <ndevos@redhat.com>
> > > 
> > > --
> > > Tested by compiling and running "qemu-img map gluster://..." with a
> > > build of the current master branch of glusterfs. Using a Fedora
> > > cloud image (in raw format) shows many SEEK procudure calls going back
> > > and forth over the network. The output of "qemu map" matches the output
> > > when run against the image on the local filesystem.
> > > ---
> > >  block/gluster.c | 159 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  configure       |  25 +++++++++
> > >  2 files changed, 184 insertions(+)
> > > 
> > > diff --git a/block/gluster.c b/block/gluster.c
> > > index 65077a0..1430010 100644
> > > --- a/block/gluster.c
> > > +++ b/block/gluster.c
> > > @@ -677,6 +677,153 @@ static int qemu_gluster_has_zero_init(BlockDriverState *bs)
> > >      return 0;
> > >  }
> > >  
> > > +#ifdef CONFIG_GLUSTERFS_SEEK_DATA
> > 
> > Why do we need to make this a compile-time option?  Version checking
> > is problematic; for instance, different distributions may have
> > backported bug fixes / features, that are not reflected by the
> > reported version number, etc..  Ideally, we can determine
> > functionality during runtime, and behave accordingly.
> 
> This will not get backported to older Gluster versions, it required a
> protocol change.
> 
> > If SEEK_DATA and SEEK_HOLE are not supported,
> > qemu_gluster_co_get_block_status can return that sectors are all
> > allocated (which is what happens in block/io.c anyway if the driver
> > doesn't support the function).
> 
> Ok, good to know.
> 
> > As long as glfs_lseek() will return error (e.g. EINVAL) for an invalid
> > whence value,  we can handle it runtime.  Does glfs_lseek() behave
> > sanely?
> 
> Unfortunately older versions of libgfapi do not return EINVAL when
> SEEK_DATA/HOLE is used. It is something we'll need to fix in the stable
> releases. We can not assume that all users have installed a version of
> the library that handles SEEK_DATA/HOLE correctly (return EINVAL) when
> there is no support in the network protocol or on the server.
> 
> To be sure that we don't get some undefined behaviour, the compile time
> check is needed.

The code could be compiled on a host with newer libgfapi, but run on a
different host with an older version. This is why having (only) compile
time checks is rarely a good idea.

Jeff's suggestion to probe the actual behaviour on the host we're
running on in .bdrv_open() sounds reasonable to me.

Kevin