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 23CB0C7EE23 for ; Tue, 30 May 2023 15:28:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232116AbjE3P2y (ORCPT ); Tue, 30 May 2023 11:28:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231787AbjE3P2t (ORCPT ); Tue, 30 May 2023 11:28:49 -0400 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D6CFC7 for ; Tue, 30 May 2023 08:28:03 -0700 (PDT) Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-6260a2522d9so21912436d6.3 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=Bksr7tzVfz7oTDe6EMCP7C+802spM/VFbpMcTjsqGmT9lt9BSo1oFr8qwxqkY2IuOM c0NlDnfniP3XSWEuciQQ14BHHS6dM8B+EhgCj+iimSD01ob9A8DU1NUg2dpSMjIy3Diz jWWA3O9nw6lwrw2v58P46mEVQGSyDQ7MZARIoqbiq79Jl857HMj6LxbPoXqz/fPOFi0a iKCTIcrRlFcZFvMizAnORVTtshYHQVlDOcnSWtFuMKyOjWctq0ZISQpsTkEjG1qsRNo+ onTbKmGx4iRjdRTQn9Hq1ouJbG9LtUAer8iU0rsvGLa0bIIFs6UaD9+4dv5NVH31DjGR N98g== X-Gm-Message-State: AC+VfDzb58XJeR2QsQ2ax3X26xbj3qQjxLsqdgvhN7Am3o2yqLaYoCAm bs6zYTnU1dJQMd7ozcmwqQmW 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-kernel@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