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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E062C43334 for ; Tue, 14 Jun 2022 15:31:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244916AbiFNPbC (ORCPT ); Tue, 14 Jun 2022 11:31:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238080AbiFNPa7 (ORCPT ); Tue, 14 Jun 2022 11:30:59 -0400 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB48E38D84 for ; Tue, 14 Jun 2022 08:30:58 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id C62B73200805; Tue, 14 Jun 2022 11:30:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 14 Jun 2022 11:30:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc:cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1655220655; x=1655307055; bh=XxPoXUSyxy YCHFWMu3HzPJ578GKZVNiQ5AXlqh/7Pvk=; b=s1IP4PpXTDTx32xhGl8vKCoGGE p3kWtOHgJid7W6E0rIFTF7ibxINsd15GcXZs3FKCsjF5C/Ucc3vFNF6FTMPiwmmO N0KQVIb/2HzZa5DiRI3SEhHmqPOpmRGTqqEIgQDtZMXU9yY+Rji2TsQ4yoGSUSPR Vq6g9KFs2N0+d1sT4J/y3TUck3iGN+M+hfiMGHssWvb3GatFDV2p4wjM7VP2UP8S mGCHd1+U3swcLXgOzebmbl0gJA43Ie4Zcz8DkyYB5kXfFxswJC8u+BdQZYRl/k84 8eSAgfn1MSaOdKckt7WVW5Y6AMxaQJ4p/lwY1gdBE2MYDocieNKYENy7YyxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655220655; x=1655307055; bh=XxPoXUSyxyYCHFWMu3HzPJ578GKZ VNiQ5AXlqh/7Pvk=; b=OaXsYS78G1WR/tcl89plo+l7XUawYj9t1+gslbEuUJ5e bF1RFOk6yYFPt4QubgPy/b72oxr+ASg6YQTXCU8MWpYuTubQ1BtnxkI+JsHV7m4h xB4LJm6tSIkKh0N303Ztsm/oYzpYihWXhfTJmVC8FwkG1hcoSLXeGk6tlS5jyadS 7I0YIZ8+7Vm0KOGyMM1bYzU5rhQctZr2san1j4+1monmIncVH3enfDAmi90xkGnP fKnkf2tLiHqOC4ZYay5gd42Jy7XXHh00G6BsxYZqkdpGeA8zcbqC8Ozp6zgqBRhv GNCpJE1T0faxknnVS5y9t1DQNDuEW8PbGhMNq16W8Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudduledgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehorhhi shcuuehurhhkohhvuceosghorhhishessghurhdrihhoqeenucggtffrrghtthgvrhhnpe ekvdekffejleelhfevhedvjeduhfejtdfhvdevieeiiedugfeugfdtjefgfeeljeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhrihhsse gsuhhrrdhioh X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Jun 2022 11:30:54 -0400 (EDT) Date: Tue, 14 Jun 2022 08:30:53 -0700 From: Boris Burkov To: Qu Wenruo Cc: Qu Wenruo , linux-btrfs@vger.kernel.org Subject: Re: [PATCH 2/2] btrfs: warn about dev extents that are inside the reserved range Message-ID: References: <7d764668-cb95-f410-4846-9a1a98e3b861@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d764668-cb95-f410-4846-9a1a98e3b861@gmx.com> Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Tue, Jun 14, 2022 at 03:48:06PM +0800, Qu Wenruo wrote: > > > On 2022/6/14 03:05, Boris Burkov wrote: > > On Mon, Jun 13, 2022 at 03:06:35PM +0800, Qu Wenruo wrote: > > > Btrfs has reserved the first 1MiB for the primary super block (at 64KiB > > > offset) and legacy programs like older bootloaders. > > > > > > This behavior is only introduced since v4.1 btrfs-progs release, > > > although kernel can ensure we never touch the reserved range of super > > > blocks, it's better to inform the end users, and a balance will resolve > > > the problem. > > > > > > Signed-off-by: Qu Wenruo > > > --- > > > fs/btrfs/volumes.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > > > index 051d124679d1..b39f4030d2ba 100644 > > > --- a/fs/btrfs/volumes.c > > > +++ b/fs/btrfs/volumes.c > > > @@ -7989,6 +7989,16 @@ static int verify_one_dev_extent(struct btrfs_fs_info *fs_info, > > > goto out; > > > } > > > > > > + /* > > > + * Very old mkfs.btrfs (before v4.1) will not respect the reserved > > > + * space. Although kernel can handle it without problem, better to > > > + * warn the users. > > > + */ > > > + if (physical_offset < BTRFS_DEFAULT_RESERVED) > > > + btrfs_warn(fs_info, > > > +"devid %llu physical %llu len %llu is inside the reserved space, balance is needed to solve this problem.", > > > > If I saw this warning, I wouldn't know what balance to run, and it's > > not obvious what to search for online either (if it's even documented). > > I think a more explicit instruction like "btrfs balance start XXXX" > > would be helpful. > > Firstly, the balance command needs extra filters, thus the command can > be pretty long, like: > > # btrfs balance start -mdrange=0..1048576 -ddrange=0..1048576 > -srange0..1048576 > > I'm not sure if this is a good idea to put all these into the already > long message. > > > > > If it's something we're ok with in general, then maybe a URL for a wiki > > page that explains the issue and the workaround would be the most > > useful. > > URL can be helpful but not always. Imagine a poor sysadmin in a noisy > server room, seeing a URL in dmesg, and has to type the full URL into > their phone, if the server has very limited network access. I don't see how the poor sysadmin would be any better off with "you need to do a balance" vs "you need to do a balance: " or "you need to do a balance using mdrange and ddrange to move the affected extents" etc.. My high level point is that you clearly have something in mind that the person needs to do in the unlikely event they hit this, but I have no idea how they are supposed to figure it out. Send a mail to our mailing list and hope you notice it? > > In fact, this error message for now will be super rare already. > > The main usage of this message is for the incoming feature, which will > allow btrfs to reserve extra space for its internal usage. > > In that case, we will allow btrfstune to set the reservation (even it's > already used by some dev extent), and btrfstune would give a commandline > how to do the balance. > > I guess I'd put all these preparation patches into the incoming on-disk > format change patchset to make it clear. > > Thanks, > Qu > > > > > > + devid, physical_offset, physical_len); > > > + > > > for (i = 0; i < map->num_stripes; i++) { > > > if (map->stripes[i].dev->devid == devid && > > > map->stripes[i].physical == physical_offset) { > > > -- > > > 2.36.1 > > >