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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 37E71C4320A for ; Wed, 18 Aug 2021 09:39:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1D26D60F39 for ; Wed, 18 Aug 2021 09:39:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231539AbhHRJkV (ORCPT ); Wed, 18 Aug 2021 05:40:21 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:58910 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231569AbhHRJkU (ORCPT ); Wed, 18 Aug 2021 05:40:20 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 8E88B1FF9D; Wed, 18 Aug 2021 09:39:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1629279585; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q25E3lESNFvdjWR7/jgy/qknNSvv2mT1La7ECgqQIxU=; b=oE+XgT1isj1PujMDKlEulEAhcX6Zj9WxZB04CHcg6oIXybHPNotkzIX6kP5J8GPDojnFnQ f1BQI3/wObEw+vFfKhPexKZRgyd3p9KIKZExGfBQUSjaFtHW2RGpSEMm3/tJ8XS4Ez2AEq bIWPOlZV1amtA6Vyt5efufElTQfbXFc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1629279585; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q25E3lESNFvdjWR7/jgy/qknNSvv2mT1La7ECgqQIxU=; b=aq4aD0IK9jDDBRrQKIXaTI2i2DPbvldIFuqKSAk4lgYUUX5g9SFV4mNZjMQpzCxHBeBxYZ OBn6qv25McxAwIBA== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay2.suse.de (Postfix) with ESMTP id 5E32FA3B93; Wed, 18 Aug 2021 09:39:45 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id C3D9BDA72C; Wed, 18 Aug 2021 11:36:48 +0200 (CEST) Date: Wed, 18 Aug 2021 11:36:48 +0200 From: David Sterba To: Johannes Thumshirn Cc: David Sterba , "linux-btrfs@vger.kernel.org" , Filipe Manana , Naohiro Aota Subject: Re: [PATCH] btrfs: zoned: exclude relocation and page writeback Message-ID: <20210818093648.GP5047@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Johannes Thumshirn , David Sterba , "linux-btrfs@vger.kernel.org" , Filipe Manana , Naohiro Aota References: <20210812142558.GI5047@suse.cz> <20210812145017.GJ5047@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Tue, Aug 17, 2021 at 02:21:51PM +0000, Johannes Thumshirn wrote: > On 12/08/2021 16:53, David Sterba wrote: > > On Thu, Aug 12, 2021 at 02:40:59PM +0000, Johannes Thumshirn wrote: > >> On 12/08/2021 16:28, David Sterba wrote: > I did some testing with the inode lock and it looks good but does not > necessarily fix all possible problems, i.e. if a ordered extent is being > split due to whatever device limits (zone append, max sector size, etc), > the assumptions we have in relocation code aren't met again. > > So the heavy lifting solution with having a dedicated temporary relocation > block group (like the treelog block group we already have for zoned) and using > regular writes looks like the only solution taking care of all of these problems. So that means that the minimum number of zones increases again, right. If the separate relocation zone fixes this and possibly other problems then fine, but as you said this is heavy weight solution. We will need a mechanims with a spare block group/zone for emergency cases where we're running out of usable metadata space and need to relocate so this could be building on the same framework. But for first implementation reserving another block group sounds easier.