Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2777274imm; Mon, 10 Sep 2018 06:24:22 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaAXzJrPCAS6XkCYYIDfHCtb3qyM9rFZp53J9uc9DGdWFNRWJeaO58N0CIzoBCFfz+Fhx9f X-Received: by 2002:a62:e08b:: with SMTP id d11-v6mr23724814pfm.214.1536585862261; Mon, 10 Sep 2018 06:24:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536585862; cv=none; d=google.com; s=arc-20160816; b=D51Yx3LeO07csLOp9fsPks534sw5WNIIObCTpV6A6htqSSTuYHqSyPqSw6ql+LNVUn BTjbo8Qe+n5Hnv50DZJINZuG6IHY1/3TXETBoKmOXkY9iQ189ymu6GvPIBduQnXLP8t3 SJJYnmFR0G3jci7+2hQECFViiegKFe3R0otmvdYoAkyHbyvO0/M09iIf8Vs/fefeyrGY ZndV4ghfy4fdogu7I7Ce/p74eJjmhgq+icJOOoUqpbNveNMKLaZCalgfROE5g98aex1y FaKRn1tIOZa7CX0sTS3RtNMwFzzVtMqoVziy+ntM6dnloxT9reTf1gwGykgLafGHRkCR V91g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:cc:to:from :date; bh=yjQM8PEetV1tCuDJsB8CkBeT5gwxfM10EnAU9yRVAp0=; b=I+K/qlzQ8W9MvpECpMoQ3tgIZFka5byuqZpGVAP45UzAeFiF+zuz4zUBJb89j5tcVz w2evGwkoeo8UlwPIRvGVPRyp6Wa7vr8yatGYbpozdRXVgCHwLfPKoYNxapAkaqgr3PTH hgZ//1pAZqNr3seGecHAHor2uWwI5rdFz47GUHg7FRsyLnS/Ttu1k5Kek3ycWQq+fT0Q ofQ2IBh1bHksc/C7DwOHUPsWmbYbHsdo93IZMYVsTiQ6mh5XFz2/QSiej9GzeMaEIxje rl4ymC3yQ0KtAartTOfh5HIa8LQbtxEnBa3ckcXxE6VokoXB98SNCALLy2hV5SC++3+A VnXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i189-v6si17773877pgd.668.2018.09.10.06.24.07; Mon, 10 Sep 2018 06:24:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728700AbeIJSRF (ORCPT + 99 others); Mon, 10 Sep 2018 14:17:05 -0400 Received: from mail.CARNet.hr ([161.53.123.6]:55295 "EHLO mail.carnet.hr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728241AbeIJSRF (ORCPT ); Mon, 10 Sep 2018 14:17:05 -0400 Received: from [2001:b68:ff:12::131] (port=35612 helo=gavran.carpriv.carnet.hr) by mail.carnet.hr with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fzM9U-00018l-KX; Mon, 10 Sep 2018 15:22:53 +0200 Received: by gavran.carpriv.carnet.hr (Postfix, from userid 1000) id 6F55C202BF; Mon, 10 Sep 2018 15:22:52 +0200 (CEST) Date: Mon, 10 Sep 2018 15:22:52 +0200 From: Valentin Vidic To: drbd-user@lists.linbit.com Cc: Jens Axboe , Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux-block@vger.kernel.org, xen-devel@lists.xenproject.org, Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20180910132252.GE26705@gavran.carpriv.carnet.hr> References: <20180829065214.23546-1-Valentin.Vidic@CARNet.hr> <20180905103649.edugijsjx4v2fbxd@mac.bytemobile.com> <20180905162756.GA26705@gavran.carpriv.carnet.hr> <20180907120337.GB11834@soda.linbit> <20180907121348.GM26705@gavran.carpriv.carnet.hr> <20180907132828.GC11834@soda.linbit> <20180907164500.GN26705@gavran.carpriv.carnet.hr> <20180907171459.GO26705@gavran.carpriv.carnet.hr> <20180908073432.GP26705@gavran.carpriv.carnet.hr> <20180910124531.GA31737@soda.linbit> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180910124531.GA31737@soda.linbit> User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: 2001:b68:ff:12::131 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on rigel.CARNet.hr X-Spam-Level: X-Spam-Status: No, score=-2.9 required=10.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Subject: Re: [DRBD-user] [PATCH] xen-blkback: Switch to closed state after releasing the backing device X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 10, 2018 at 02:45:31PM +0200, Lars Ellenberg wrote: > On Sat, Sep 08, 2018 at 09:34:32AM +0200, Valentin Vidic wrote: > > On Fri, Sep 07, 2018 at 07:14:59PM +0200, Valentin Vidic wrote: > > > In fact the first one is the original code path before I modified > > > blkback. The problem is it gets executed async from workqueue so > > > it might not always run before the call to drbdadm secondary. > > > > As the DRBD device gets released only when the last IO request > > has finished, I found a way to check and wait for this in the > > block-drbd script: > > > --- block-drbd.orig 2018-09-08 09:07:23.499648515 +0200 > > +++ block-drbd 2018-09-08 09:28:12.892193649 +0200 > > @@ -230,6 +230,24 @@ > > and so cannot be mounted ${m2}${when}." > > } > > > > +wait_for_inflight() > > +{ > > + local dev="$1" > > + local inflight="/sys/block/${dev#/dev/}/inflight" > > + local rd wr > > + > > + if ! [ -f "$inflight" ]; then > > + return > > + fi > > + > > + while true; do > > + read rd wr < $inflight > > + if [ "$rd" = "0" -a "$wr" = "0" ]; then > > If it is "idle" now, but still "open", > this will not sleep, and still fail the demotion below. True, but in this case blkback is holding it open until all the writes have finished and the last write closes the device. Since fuser can't check blkback this is an approximation that seems to work because I don't get any failed drbdadm calls now. > You try to help it by "waiting forever until it appears to be idle". > I suggest to at least limit the retries by iteration or time. > And also (or, instead; but you'd potentially get a number of > "scary messages" in the logs) add something like: Ok, should I open a PR to discuss this change further? > Or, well, yes, fix blkback to not "defer" the final close "too long", > if at all possible. blkback needs to finish the writes on shutdown or I get a fsck errors on next boot. Ideally XenbusStateClosed should be delayed until the device release but currently it does not seem possible without breaking other things. -- Valentin