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 36BA1C7EE2C for ; Tue, 30 May 2023 15:28:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232059AbjE3P2w (ORCPT ); Tue, 30 May 2023 11:28:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231887AbjE3P2u (ORCPT ); Tue, 30 May 2023 11:28:50 -0400 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F6F9F7 for ; Tue, 30 May 2023 08:28:03 -0700 (PDT) Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-3f6c229b42bso24010761cf.0 for ; Tue, 30 May 2023 08:28:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685460482; x=1688052482; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YR3Dr4CMzNNzM1c3LGHePU3pSGMOwf2n9BmkTIJqoZY=; b=CRsK8gGQFDSd1UOLCAjFRTsiWoboLHuqbZ4/IhY6fMYCJv4Up06Pcqhha0p5qY7PTW KVg7yPcSi7gqF0sS1Z001pA9ymZufwnjBjlyjYM68TtOuD6LIRbFA0sgWfoxseo1VJag jdK+DQtKzGgUnRbErhUpKb4DCIZitoBFatokfioN/Z4scrhNSPJkLoBtxw1w8z8L2Jn4 krOjv8OhYXFy3hDq5RMN9N/CQlKBnxeECoUffdAhVBe49sy6nvUVkXQvStJLQtHkzh4A gVhNmKpYPxyAA/b7FWYJtalUL9snyxymG+rqyuSOB1SCjO7eVrLxBXhzcp3jxy3qmP0J bjlg== X-Gm-Message-State: AC+VfDwOZrRUSyFc4N1cvLI2j+7lriXd/J+9VMtgKhdC0WdgGFuufQVz 8/qeqJA/pMmP4XG/4x5vj5XT X-Google-Smtp-Source: ACHHUZ55tRVn6w2eePAhc6/qm8CJME6WENqz9zraKI3ZQacG7/5mnhJynvxY+ok00f1xtu5eZcDZQA== X-Received: by 2002:ad4:5ae4:0:b0:625:aa1a:9384 with SMTP id c4-20020ad45ae4000000b00625aa1a9384mr2941055qvh.64.1685460482224; Tue, 30 May 2023 08:28:02 -0700 (PDT) Received: from localhost (pool-68-160-166-30.bstnma.fios.verizon.net. [68.160.166.30]) by smtp.gmail.com with ESMTPSA id o12-20020a05620a15cc00b0074d489e517csm4106298qkm.24.2023.05.30.08.28.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 May 2023 08:28:01 -0700 (PDT) Date: Tue, 30 May 2023 11:28:00 -0400 From: Mike Snitzer To: Joe Thornber Cc: Jens Axboe , Christoph Hellwig , Theodore Ts'o , Sarthak Kukreti , dm-devel@redhat.com, "Michael S. Tsirkin" , "Darrick J. Wong" , Brian Foster , Bart Van Assche , Dave Chinner , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Joe Thornber , Andreas Dilger , Stefan Hajnoczi , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Jason Wang , Alasdair Kergon Subject: Re: [PATCH v7 0/5] Introduce provisioning primitives Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, May 30 2023 at 10:55P -0400, Joe Thornber wrote: > On Tue, May 30, 2023 at 3:02 PM Mike Snitzer wrote: > > > > > Also Joe, for you proposed dm-thinp design where you distinquish > > between "provision" and "reserve": Would it make sense for REQ_META > > (e.g. all XFS metadata) with REQ_PROVISION to be treated as an > > LBA-specific hard request? Whereas REQ_PROVISION on its own provides > > more freedom to just reserve the length of blocks? (e.g. for XFS > > delalloc where LBA range is unknown, but dm-thinp can be asked to > > reserve space to accomodate it). > > > > My proposal only involves 'reserve'. Provisioning will be done as part of > the usual io path. OK, I think we'd do well to pin down the top-level block interfaces in question. Because this patchset's block interface patch (2/5) header says: "This patch also adds the capability to call fallocate() in mode 0 on block devices, which will send REQ_OP_PROVISION to the block device for the specified range," So it wires up blkdev_fallocate() to call blkdev_issue_provision(). A user of XFS could then use fallocate() for user data -- which would cause thinp's reserve to _not_ be used for critical metadata. The only way to distinquish the caller (between on-behalf of user data vs XFS metadata) would be REQ_META? So should dm-thinp have a REQ_META-based distinction? Or just treat all REQ_OP_PROVISION the same? Mike