On Tue, Mar 08, 2016 at 01:53:26PM +0100, Kevin Wolf wrote: > 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 <nde...@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.
Oh, yes, that is possible. glfs_lseek() is not a new function, so the symbol version did not need to change. > Jeff's suggestion to probe the actual behaviour on the host we're > running on in .bdrv_open() sounds reasonable to me. Yes, it sure is. I'll send a v2 patch soon. Thanks, Niels