From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92D9FC4338F for ; Tue, 24 Aug 2021 20:40:33 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DA04A611C8 for ; Tue, 24 Aug 2021 20:40:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DA04A611C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:51312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIdDj-00066m-PK for qemu-devel@archiver.kernel.org; Tue, 24 Aug 2021 16:40:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIdD1-0005JW-QR; Tue, 24 Aug 2021 16:39:47 -0400 Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]:42690) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mIdCz-0007a8-OV; Tue, 24 Aug 2021 16:39:47 -0400 Received: by mail-il1-x134.google.com with SMTP id s16so21792424ilo.9; Tue, 24 Aug 2021 13:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ypi97dFi0SNrCvXciPS0Mf0qGA41A7chKDHbfxhBvbE=; b=qdNoEhCXR/X7C64pQAm2mY2iMYC2ckVFHyPlf3znI0yL800abmoOykbbJ3+iXF+vPt YiOeupeLx0d/bS77XUyk3uOKz+DrioMuoSXa9fMfsmDJ6F6lW7v+MHo5i00ux4J0v45S tsf2+VanTMyfCuCb26WxIcYLsQ+X4Psw+AX6DpIjheEUc2vTLIyCOFjmRSJyP7nntG9o T3DQYnLaZta5Ov6ZxPYPu93OWd+9X1THqlTINpUXC6STAaHUn5p2TEuqXH8w7GYdTyVR In6GpaYIl5hXbJCzzIP0xqZV299xo/GDVfepekdS9zvA73gDJNNqNjJeW5Ertf1FBfyP 4+Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ypi97dFi0SNrCvXciPS0Mf0qGA41A7chKDHbfxhBvbE=; b=OIjg3SH4bilvTkxykGYniMVj1tNlKEAytdmamnQJLStWdZAlzbMwCSwBXRVyC8IIU7 dxy/G03zp0j4E0zNDcwwDAv/SlkW8FUW5Rx46gHkVuK2bn5NcnFN3Ka1Nm6gzsrogYfu P2l24r95D1tmC5E7FVGYRvR1uikOMb0EyIMA2PFhjZQ0XQoWfUOaXsVVSPajInUH+0jm AhG2Zpn5zqGnHZ1V4XCeD3/LAeni7WLY7bWjV+sfQxGqdIk/5JdtJKMKe+gDrR2P+jO7 o4CgwDzzQnJLClCm4Lyy5QTFU3i7VlN/G5FCesP1sTgpQ2P+3LvNlSvncJ9dcmocJW1l Yytw== X-Gm-Message-State: AOAM532Z6ofrEfMRB4Az9jLL5HTVHxkCp7gDs+WZZxcOxjePvUywvZJs B1RdzIwCcyJlh1hLWUidRCijmSs7Thnvz25jtvc= X-Google-Smtp-Source: ABdhPJxDWEUf2/kTE7gp1v3t3uTvvS+YlWY09E7HNwI8LgzKK2fEvMY4rSuSmRUk4myZmz64iD9XjVso+tGdIngkczo= X-Received: by 2002:a92:8707:: with SMTP id m7mr28358743ild.177.1629837583504; Tue, 24 Aug 2021 13:39:43 -0700 (PDT) MIME-Version: 1.0 References: <20210810134124.18523-1-pl@kamp.de> <83955263-3d55-7fe8-709a-7729edf48573@kamp.de> In-Reply-To: <83955263-3d55-7fe8-709a-7729edf48573@kamp.de> From: Ilya Dryomov Date: Tue, 24 Aug 2021 22:39:27 +0200 Message-ID: Subject: Re: [PATCH V2] block/rbd: implement bdrv_co_block_status To: Peter Lieven Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::134; envelope-from=idryomov@gmail.com; helo=mail-il1-x134.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Ilya Dryomov , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-block@nongnu.org, ct@flyingcircus.io, qemu-devel@nongnu.org, Paolo Bonzini , Max Reitz , Jason Dillaman Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Aug 23, 2021 at 11:38 AM Peter Lieven wrote: > > Am 22.08.21 um 23:02 schrieb Ilya Dryomov: > > On Tue, Aug 10, 2021 at 3:41 PM Peter Lieven wrote: > >> the qemu rbd driver currently lacks support for bdrv_co_block_status. > >> This results mainly in incorrect progress during block operations (e.g. > >> qemu-img convert with an rbd image as source). > >> > >> This patch utilizes the rbd_diff_iterate2 call from librbd to detect > >> allocated and unallocated (all zero areas). > >> > >> To avoid querying the ceph OSDs for the answer this is only done if > >> the image has the fast-diff features which depends on the object-map > > Hi Peter, > > > > Nit: "has the fast-diff feature which depends on the object-map and > > exclusive-lock features" > > > will reword in V3. > > > > > >> and exclusive-lock. In this case it is guaranteed that the information > >> is present in memory in the librbd client and thus very fast. > >> > >> If fast-diff is not available all areas are reported to be allocated > >> which is the current behaviour if bdrv_co_block_status is not implemented. > >> > >> Signed-off-by: Peter Lieven > >> --- > >> V1->V2: > >> - add commit comment [Stefano] > >> - use failed_post_open [Stefano] > >> - remove redundant assert [Stefano] > >> - add macro+comment for the magic -9000 value [Stefano] > >> - always set *file if its non NULL [Stefano] > >> > >> block/rbd.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 125 insertions(+) > >> > >> diff --git a/block/rbd.c b/block/rbd.c > >> index dcf82b15b8..8692e76f40 100644 > >> --- a/block/rbd.c > >> +++ b/block/rbd.c > >> @@ -88,6 +88,7 @@ typedef struct BDRVRBDState { > >> char *namespace; > >> uint64_t image_size; > >> uint64_t object_size; > >> + uint64_t features; > >> } BDRVRBDState; > >> > >> typedef struct RBDTask { > >> @@ -983,6 +984,13 @@ static int qemu_rbd_open(BlockDriverState *bs, QDict *options, int flags, > >> s->image_size = info.size; > >> s->object_size = info.obj_size; > >> > >> + r = rbd_get_features(s->image, &s->features); > >> + if (r < 0) { > >> + error_setg_errno(errp, -r, "error getting image features from %s", > >> + s->image_name); > >> + goto failed_post_open; > >> + } > > The object-map and fast-diff features can be enabled/disabled while the > > image is open so this should probably go to qemu_rbd_co_block_status(). > > > >> + > >> /* If we are using an rbd snapshot, we must be r/o, otherwise > >> * leave as-is */ > >> if (s->snap != NULL) { > >> @@ -1259,6 +1267,122 @@ static ImageInfoSpecific *qemu_rbd_get_specific_info(BlockDriverState *bs, > >> return spec_info; > >> } > >> > >> +typedef struct rbd_diff_req { > >> + uint64_t offs; > >> + uint64_t bytes; > >> + int exists; > >> +} rbd_diff_req; > >> + > >> +/* > >> + * rbd_diff_iterate2 allows to interrupt the exection by returning a negative > >> + * value in the callback routine. Choose a value that does not conflict with > >> + * an existing exitcode and return it if we want to prematurely stop the > >> + * execution because we detected a change in the allocation status. > >> + */ > >> +#define QEMU_RBD_EXIT_DIFF_ITERATE2 -9000 > >> + > >> +static int qemu_rbd_co_block_status_cb(uint64_t offs, size_t len, > >> + int exists, void *opaque) > >> +{ > >> + struct rbd_diff_req *req = opaque; > >> + > >> + assert(req->offs + req->bytes <= offs); > >> + > >> + if (req->exists && offs > req->offs + req->bytes) { > >> + /* > >> + * we started in an allocated area and jumped over an unallocated area, > >> + * req->bytes contains the length of the allocated area before the > >> + * unallocated area. stop further processing. > >> + */ > >> + return QEMU_RBD_EXIT_DIFF_ITERATE2; > >> + } > >> + if (req->exists && !exists) { > >> + /* > >> + * we started in an allocated area and reached a hole. req->bytes > >> + * contains the length of the allocated area before the hole. > >> + * stop further processing. > >> + */ > >> + return QEMU_RBD_EXIT_DIFF_ITERATE2; > >> + } > >> + if (!req->exists && exists && offs > req->offs) { > >> + /* > >> + * we started in an unallocated area and hit the first allocated > >> + * block. req->bytes must be set to the length of the unallocated area > >> + * before the allocated area. stop further processing. > >> + */ > >> + req->bytes = offs - req->offs; > >> + return QEMU_RBD_EXIT_DIFF_ITERATE2; > >> + } > >> + > >> + /* > >> + * assert that we catched all cases above and allocation state has not > > catched -> caught > > > >> + * changed during callbacks. > >> + */ > >> + assert(exists == req->exists || !req->bytes); > >> + req->exists = exists; > >> + > >> + /* > >> + * assert that we either return an unallocated block or have got callbacks > >> + * for all allocated blocks present. > >> + */ > >> + assert(!req->exists || offs == req->offs + req->bytes); > >> + req->bytes = offs + len - req->offs; > >> + > >> + return 0; > >> +} > >> + > >> +static int coroutine_fn qemu_rbd_co_block_status(BlockDriverState *bs, > >> + bool want_zero, int64_t offset, > >> + int64_t bytes, int64_t *pnum, > >> + int64_t *map, > >> + BlockDriverState **file) > >> +{ > >> + BDRVRBDState *s = bs->opaque; > >> + int ret, r; > >> + struct rbd_diff_req req = { .offs = offset }; > >> + > >> + assert(offset + bytes <= s->image_size); > >> + > >> + /* default to all sectors allocated */ > >> + ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID; > > I'm a little confused by the meaning of these flags (but I haven't > > looked at the other drivers yet). Looks like this patch always sets > > BDRV_BLOCK_OFFSET_VALID (makes sense since the "host" offset is always > > known for rbd) and returns either BDRV_BLOCK_DATA or BDRV_BLOCK_ZERO. > > > > DATA ZERO OFFSET_VALID > > t t t sectors read as zero, returned file is zero at offset > > t f t sectors read as valid from file at offset > > f t t sectors preallocated, read as zero, returned file not > > necessarily zero at offset > > f f t sectors preallocated but read from backing_hd, > > returned file contains garbage at offset > > > > What about the first case (BDRV_BLOCK_DATA | BDRV_BLOCK_ZERO)? > > What is the practical difference to just BDRV_BLOCK_ZERO? > > > Actually I don't know, I adapted the flags from other drivers. Looking at your > table it seems that DATA + ZERO would be more appropriate for rbd, right? It would seem that way but I haven't had a chance to look at how qemu block layer interprets these yet. > > We do not preallocate in qem/rbd yet. I guess it depends on what preallocated means here, if it talks about the logical address space or the physical sectors. If the former, rbd can be thought of as always preallocated. Separately, rbd_read() at an offset that corresponds to an unallocated area (including in parent image(s)) would always return zeroes. I wonder if that is the same as "returned file is zero at offset". > > > > > >> + if (map) { > >> + *map = offset; > >> + } > >> + if (file) { > >> + *file = bs; > >> + } > > A comment in block_int.h says that map and file are guaranteed to be > > non-NULL so these tests seem redundant? > > > This is also Copy&Paste from other drivers, will change it (and maybe > > in other drivers as well). > > > > > > >> + *pnum = bytes; > >> + > >> + /* RBD image does not support fast-diff */ > >> + if (!(s->features & RBD_FEATURE_FAST_DIFF)) { > >> + goto out; > >> + } > > Need to make sure that fast-diff is valid here: call rbd_get_flags() > > on the image and test for !RBD_FLAG_FAST_DIFF_INVALID. > > > Do I have to check for feature FAST_DIFF + flag !FAST_DIFF_INVALID or > > is the second enough? Is this call fast? For both. The call should be as fast as rbd_get_features(). Thanks, Ilya