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 3C5EBE95A92 for ; Sun, 8 Oct 2023 23:27:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344975AbjJHX1g (ORCPT ); Sun, 8 Oct 2023 19:27:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344965AbjJHX1f (ORCPT ); Sun, 8 Oct 2023 19:27:35 -0400 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9BFEB3 for ; Sun, 8 Oct 2023 16:27:32 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-27b22de9b5bso1973821a91.3 for ; Sun, 08 Oct 2023 16:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1696807652; x=1697412452; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aS5wnORfWJ02Ic4UlNgXgG7erca/6rPk7A+dIWgu1xE=; b=ar+F8kCJJYhocpH7678ttAXERmoI3yDavLymH+R8n+35dyDP58p8hJzK8gVAcQnWwh RirkN49+Qt+O1zUgU1OfDzkBhTeE7796uHFvZHa0gFv1zP8QKIuNAFcbsljod+Gb60La MiIgpSGI49duQ1w0jRtwOZUBq8c/h1RdDsSXqtVptZrGgUVqObEK4jKbEN+3G+hlm0ml ePJVD+GKPlQoTH1agTEdIi2/BnJZj1h1L0HyVx2nEp9mWs0vsmmgb5Sk3UHSkc6v7D73 BYJ099PQo8RtsN0oxQog8POX7NVf/yv46dlGYNpDNeCGi8L0E4fi7PhSIhNw4HyeN8f9 AY/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696807652; x=1697412452; h=in-reply-to: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=aS5wnORfWJ02Ic4UlNgXgG7erca/6rPk7A+dIWgu1xE=; b=KqcTShGQGYsZIQH0E/gKxxjjMdfucX2pc2l8t6UhTwr9F1WqZf50qR7kJrVOnvKIDF /KBh7RMdK7sZpZMmD/GcHPjoc1IrM9pV3CpQTqzzt/klq2I9D9cqnYrx61yrtDIajgbZ 7+MvsyNFj8FUR+P3p3JtzBdEYNX7uZZq5/BQn/6WDtM5aeb8XHYxqbPWCvXhtzh2H6zQ a+3gabMkabyaqsusl7D13EQRjakUA17Xox4wcu3vuTFuStCRUpIxF3HdEwX4XiDoEHLo 95q+9HWsV5m4w4GPOpwlrWzxZGfeq0KJ9qZlYLi7IQ2WH3BECRqx+Nd0egYvPEFK3did fACw== X-Gm-Message-State: AOJu0YwRN/WAmenKfY9Khp8MFN5a/d7pDjg1RD+AB6LgZCPrNXGhP/Fp +Lu08GCH4r6ECBuk9cMBXE/OEA== X-Google-Smtp-Source: AGHT+IGc6rajtNnnrMTfh5c1WN82wupHs7ltG+HbFIhM8I8+f4cQIL9QXxrn5Dk/ibag1JxJfP4QTg== X-Received: by 2002:a17:90b:4b06:b0:273:e689:8dfc with SMTP id lx6-20020a17090b4b0600b00273e6898dfcmr11740281pjb.32.1696807652373; Sun, 08 Oct 2023 16:27:32 -0700 (PDT) Received: from dread.disaster.area (pa49-180-20-59.pa.nsw.optusnet.com.au. [49.180.20.59]) by smtp.gmail.com with ESMTPSA id az12-20020a17090b028c00b0026d4100e0e8sm6954450pjb.10.2023.10.08.16.27.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Oct 2023 16:27:31 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qpdBI-00BHvI-0p; Mon, 09 Oct 2023 10:27:28 +1100 Date: Mon, 9 Oct 2023 10:27:28 +1100 From: Dave Chinner To: Sarthak Kukreti Cc: dm-devel@redhat.com, linux-block@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jens Axboe , Alasdair Kergon , Mike Snitzer , Christoph Hellwig , Brian Foster , Theodore Ts'o , Andreas Dilger , Bart Van Assche , "Darrick J. Wong" Subject: Re: [PATCH v8 5/5] block: Pass unshare intent via REQ_OP_PROVISION Message-ID: References: <20231007012817.3052558-1-sarthakkukreti@chromium.org> <20231007012817.3052558-6-sarthakkukreti@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231007012817.3052558-6-sarthakkukreti@chromium.org> Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Fri, Oct 06, 2023 at 06:28:17PM -0700, Sarthak Kukreti wrote: > Allow REQ_OP_PROVISION to pass in an extra REQ_UNSHARE bit to > annotate unshare requests to underlying layers. Layers that support > FALLOC_FL_UNSHARE will be able to use this as an indicator of which > fallocate() mode to use. > > Suggested-by: Darrick J. Wong > Signed-off-by: Sarthak Kukreti > --- > block/blk-lib.c | 6 +++++- > block/fops.c | 6 ++++-- > drivers/block/loop.c | 35 +++++++++++++++++++++++++++++------ > include/linux/blk_types.h | 3 +++ > include/linux/blkdev.h | 3 ++- > 5 files changed, 43 insertions(+), 10 deletions(-) I have no idea how filesystems (or even userspace applications, for that matter) are supposed to use this - they have no idea if the underlying block device has shared blocks for LBA ranges it already has allocated and provisioned. IOWs, I don't know waht the semantics of this function is, it is not documented anywhere, and there is no use case present that tells me how it might get used. Yes, unshare at the file level means the filesystem tries to break internal data extent sharing, but if the block layers or backing devices are doing deduplication and sharing unknown to the application or filesystem, how do they ever know that this operation might need to be performed? In what cases do we need to be able to unshare block device ranges, and how is that different to the guarantees that REQ_PROVISION is already supposed to give for provisioned ranges that are then subsequently shared by the block device (e.g. by snapshots)? Also, from an API perspective, this is an "unshare" data operation, not a "provision" operation. Hence I'd suggest that the API should be blkdev_issue_unshare() rather than optional behaviour to _provision() which - before this patch - had clear and well defined meaning.... Cheers, Dave. -- Dave Chinner david@fromorbit.com 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 us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8A9D9E95A67 for ; Sun, 8 Oct 2023 23:27:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696807665; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=gy6nrA8k5/e+cGtK5lCJYynwJ42cdEX4HLexYGcxBMs=; b=ONTvz1KRPQMbdcLTxfw5iOM+tWKDWgKYkXInBJd51OXmKIFiirMRGVKQzHS6sDtJdm+vs9 qIZYcOhr0VEe71/zlbNTysCbgGxKrghBQBVYok03EmU86lElJuEs1PiW2BW5OsVH+biUeb ADDTxAzffopxEAExnJfxCFc/8YfxZxU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-497-fCZHVuYLNzavs3D_VvtKFw-1; Sun, 08 Oct 2023 19:27:41 -0400 X-MC-Unique: fCZHVuYLNzavs3D_VvtKFw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 29DD1805BAC; Sun, 8 Oct 2023 23:27:40 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5123420268C8; Sun, 8 Oct 2023 23:27:37 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id D70761946595; Sun, 8 Oct 2023 23:27:36 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id DDA01194658C for ; Sun, 8 Oct 2023 23:27:35 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id AA4CE20268CB; Sun, 8 Oct 2023 23:27:35 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A206520268C8 for ; Sun, 8 Oct 2023 23:27:35 +0000 (UTC) Received: from us-smtp-inbound-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 835738039C1 for ; Sun, 8 Oct 2023 23:27:35 +0000 (UTC) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-446-OtLCHxCVOrWRqFQj6zpSKQ-1; Sun, 08 Oct 2023 19:27:33 -0400 X-MC-Unique: OtLCHxCVOrWRqFQj6zpSKQ-1 Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-2773523b2b6so2259451a91.2 for ; Sun, 08 Oct 2023 16:27:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696807652; x=1697412452; h=in-reply-to: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=aS5wnORfWJ02Ic4UlNgXgG7erca/6rPk7A+dIWgu1xE=; b=bKh0VGykulLiTQijSW6ntbokXl2r8G+i+yT8tJfOrD02VKG8f0Qm+AWsoLc5UV2BzL JaRFHJkbuBPCDl1A6pQ4hyRWBuJ7UVHX5e28IqzOWnbMjtc+oxE4VBPa04Kz+yIq8t1g zOKP+MLZpekZ830UDFfiFfBAqTVUtqC6lG6LjNGmI0Uv4zG+c77BkxNqNgCrXwiWy8av SrhfxMkGwW3Oo1T/A5VSbWAvSckLBAU2j9GopD8dloHLtml6p1tTM/+jIuU2w7LdgJzr rF5AWTlVifSMEsh7lNsTpebSlidmIRzWgFGSHifywJY2ZN0GfH29WyiyUOGcHTEEYl2Z 5taA== X-Gm-Message-State: AOJu0YwvhD/e4UTZlJPsfxs4/5XbfnvrXuETfxaMxYmCyOn6wB6fOcOX lkz73+4N0kFKh5GJZ4lMDJQftQ== X-Google-Smtp-Source: AGHT+IGc6rajtNnnrMTfh5c1WN82wupHs7ltG+HbFIhM8I8+f4cQIL9QXxrn5Dk/ibag1JxJfP4QTg== X-Received: by 2002:a17:90b:4b06:b0:273:e689:8dfc with SMTP id lx6-20020a17090b4b0600b00273e6898dfcmr11740281pjb.32.1696807652373; Sun, 08 Oct 2023 16:27:32 -0700 (PDT) Received: from dread.disaster.area (pa49-180-20-59.pa.nsw.optusnet.com.au. [49.180.20.59]) by smtp.gmail.com with ESMTPSA id az12-20020a17090b028c00b0026d4100e0e8sm6954450pjb.10.2023.10.08.16.27.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Oct 2023 16:27:31 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qpdBI-00BHvI-0p; Mon, 09 Oct 2023 10:27:28 +1100 Date: Mon, 9 Oct 2023 10:27:28 +1100 From: Dave Chinner To: Sarthak Kukreti Message-ID: References: <20231007012817.3052558-1-sarthakkukreti@chromium.org> <20231007012817.3052558-6-sarthakkukreti@chromium.org> MIME-Version: 1.0 In-Reply-To: <20231007012817.3052558-6-sarthakkukreti@chromium.org> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Subject: Re: [dm-devel] [PATCH v8 5/5] block: Pass unshare intent via REQ_OP_PROVISION X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , Christoph Hellwig , Theodore Ts'o , "Darrick J. Wong" , Brian Foster , Bart Van Assche , Mike Snitzer , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, dm-devel@redhat.com, Andreas Dilger , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Alasdair Kergon Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: fromorbit.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Oct 06, 2023 at 06:28:17PM -0700, Sarthak Kukreti wrote: > Allow REQ_OP_PROVISION to pass in an extra REQ_UNSHARE bit to > annotate unshare requests to underlying layers. Layers that support > FALLOC_FL_UNSHARE will be able to use this as an indicator of which > fallocate() mode to use. > > Suggested-by: Darrick J. Wong > Signed-off-by: Sarthak Kukreti > --- > block/blk-lib.c | 6 +++++- > block/fops.c | 6 ++++-- > drivers/block/loop.c | 35 +++++++++++++++++++++++++++++------ > include/linux/blk_types.h | 3 +++ > include/linux/blkdev.h | 3 ++- > 5 files changed, 43 insertions(+), 10 deletions(-) I have no idea how filesystems (or even userspace applications, for that matter) are supposed to use this - they have no idea if the underlying block device has shared blocks for LBA ranges it already has allocated and provisioned. IOWs, I don't know waht the semantics of this function is, it is not documented anywhere, and there is no use case present that tells me how it might get used. Yes, unshare at the file level means the filesystem tries to break internal data extent sharing, but if the block layers or backing devices are doing deduplication and sharing unknown to the application or filesystem, how do they ever know that this operation might need to be performed? In what cases do we need to be able to unshare block device ranges, and how is that different to the guarantees that REQ_PROVISION is already supposed to give for provisioned ranges that are then subsequently shared by the block device (e.g. by snapshots)? Also, from an API perspective, this is an "unshare" data operation, not a "provision" operation. Hence I'd suggest that the API should be blkdev_issue_unshare() rather than optional behaviour to _provision() which - before this patch - had clear and well defined meaning.... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel