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.133.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 4C8F6ECAAD8 for ; Wed, 21 Sep 2022 15:39:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663774779; 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=4lzbejESpK+sOuU0vc1/Wo28CL7S7/A2yvs8JSQkw6c=; b=Zwjd2mlZu3QP8uxGXQ5b7+qypKgcydUalWlZ3aCnxRJJfePYYXC8PbxvMMMMS7EQtIcOjH eu9thgcgDVH+LkJBCbYfYkaPaX/BckxB4+6NUWQE4vy2RxyKpD7yOJ3ry3Hpqtsi9238bs HypcksiI4iLl/Kf4c7FEa4ZgHxku63Q= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-412-Fdus6Gr2OfaxiTBF0sUr-A-1; Wed, 21 Sep 2022 11:39:35 -0400 X-MC-Unique: Fdus6Gr2OfaxiTBF0sUr-A-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F52C3C0D855; Wed, 21 Sep 2022 15:39:34 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id E42CA49BB61; Wed, 21 Sep 2022 15:39:33 +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 C41A119465B1; Wed, 21 Sep 2022 15:39:33 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 24BBF19465A4 for ; Wed, 21 Sep 2022 15:39:21 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 15B8D40C6EC6; Wed, 21 Sep 2022 15:39:21 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast10.extmail.prod.ext.rdu2.redhat.com [10.11.55.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D8A6040C6EC5 for ; Wed, 21 Sep 2022 15:39:20 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (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 B42EB1C07585 for ; Wed, 21 Sep 2022 15:39:20 +0000 (UTC) Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-75-ECHfg2KCPHmJO5zKhUM4FA-1; Wed, 21 Sep 2022 11:39:19 -0400 X-MC-Unique: ECHfg2KCPHmJO5zKhUM4FA-1 Received: by mail-qv1-f72.google.com with SMTP id y7-20020ad45307000000b004ac7fd46495so4571059qvr.23 for ; Wed, 21 Sep 2022 08:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=qdyn6X4um0jOmxbVbIVJ/ritfQu0YXAwmpkbuktXlco=; b=wPuLIFJgq5N0uoArpINyG47xnzpxQTv61IEREY3ypypLQ/CTFHmMqyy5MwEcV+LnzA c7x+Uqvl2lapo3nFnCLZIVm3gCw9y7jxPOYl3TBkCOC/rNG1/t9OB+VDn5vlDyD/3KAr Uoaxl1B16xRfKfIKLefi+sUZTn+OOKQ/MLqqkgxH8MnrPI5rTXYKgKVKhGvp87ixh2Ft 7lqfh2z1SGg8GmbDuQGsbgldNKimfkJDlogJhkyLUXV+ZOhqqU7bHRtYDWcp2okqeQjd xyAlq7To1Xp9I+4BTN8xvd+SWg8xz0XD7qvhrCdapYWC43F4dP9FroJ25J/dvMUasoLP n7RQ== X-Gm-Message-State: ACrzQf1umoJsrw1kTOte4Gl+5Q5PKCAeIUifBlZT3+53e7dkLGpRt83z kHAKzcrYKbc7wwD0rWkRWi7a8NMN7SxD5CT7sy6D1BIq1M+lh7p2UjEnX8UHWNhlnDf4st7FyIC qN9gVoE1Aw82WOQs= X-Received: by 2002:ac8:5a13:0:b0:35c:e9b0:430b with SMTP id n19-20020ac85a13000000b0035ce9b0430bmr13368702qta.472.1663774758895; Wed, 21 Sep 2022 08:39:18 -0700 (PDT) X-Google-Smtp-Source: AMsMyM594zwhYYo497Gbf01p/qkC0k5EzOtGiVtB6LsJU02syDsCgiXnnQXhpz8ER02eO+Lp+Qd8CQ== X-Received: by 2002:ac8:5a13:0:b0:35c:e9b0:430b with SMTP id n19-20020ac85a13000000b0035ce9b0430bmr13368681qta.472.1663774758598; Wed, 21 Sep 2022 08:39:18 -0700 (PDT) Received: from bfoster (c-24-61-119-116.hsd1.ma.comcast.net. [24.61.119.116]) by smtp.gmail.com with ESMTPSA id f25-20020ac84659000000b0035ccd148026sm1791612qto.69.2022.09.21.08.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 08:39:18 -0700 (PDT) Date: Wed, 21 Sep 2022 11:39:15 -0400 From: Brian Foster To: Sarthak Kukreti Message-ID: References: <20220915164826.1396245-1-sarthakkukreti@google.com> <20220915164826.1396245-5-sarthakkukreti@google.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 Subject: Re: [dm-devel] [PATCH RFC 4/8] fs: Introduce FALLOC_FL_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 , Gwendal Grignou , Theodore Ts'o , "Michael S . Tsirkin" , Jason Wang , Bart Van Assche , Mike Snitzer , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-block@vger.kernel.org, dm-devel@redhat.com, Andreas Dilger , Daniil Lunev , Stefan Hajnoczi , Paolo Bonzini , linux-ext4@vger.kernel.org, Evan Green , Alasdair Kergon Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Sep 16, 2022 at 02:02:31PM -0700, Sarthak Kukreti wrote: > On Fri, Sep 16, 2022 at 4:56 AM Brian Foster wrote: > > > > On Thu, Sep 15, 2022 at 09:48:22AM -0700, Sarthak Kukreti wrote: > > > From: Sarthak Kukreti > > > > > > FALLOC_FL_PROVISION is a new fallocate() allocation mode that > > > sends a hint to (supported) thinly provisioned block devices to > > > allocate space for the given range of sectors via REQ_OP_PROVISION. > > > > > > Signed-off-by: Sarthak Kukreti > > > --- > > > block/fops.c | 7 ++++++- > > > include/linux/falloc.h | 3 ++- > > > include/uapi/linux/falloc.h | 8 ++++++++ > > > 3 files changed, 16 insertions(+), 2 deletions(-) > > > > > > diff --git a/block/fops.c b/block/fops.c > > > index b90742595317..a436a7596508 100644 > > > --- a/block/fops.c > > > +++ b/block/fops.c > > ... > > > @@ -661,6 +662,10 @@ static long blkdev_fallocate(struct file *file, int mode, loff_t start, > > > error = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT, > > > len >> SECTOR_SHIFT, GFP_KERNEL); > > > break; > > > + case FALLOC_FL_PROVISION: > > > + error = blkdev_issue_provision(bdev, start >> SECTOR_SHIFT, > > > + len >> SECTOR_SHIFT, GFP_KERNEL); > > > + break; > > > default: > > > error = -EOPNOTSUPP; > > > } > > > > Hi Sarthak, > > > > Neat mechanism.. I played with something very similar in the past (that > > was much more crudely hacked up to target dm-thin) to allow filesystems > > to request a thinly provisioned device to allocate blocks and try to do > > a better job of avoiding inactivation when overprovisioned. > > > > One thing I'm a little curious about here.. what's the need for a new > > fallocate mode? On a cursory glance, the provision mode looks fairly > > analogous to normal (mode == 0) allocation mode with the exception of > > sending the request down to the bdev. blkdev_fallocate() already maps > > some of the logical falloc modes (i.e. punch hole, zero range) to > > sending write sames or discards, etc., and it doesn't currently look > > like it supports allocation mode, so could it not map such requests to > > the underlying REQ_OP_PROVISION op? > > > > I guess the difference would be at the filesystem level where we'd > > probably need to rely on a mount option or some such to control whether > > traditional fallocate issues provision ops (like you've implemented for > > ext4) vs. the specific falloc command, but that seems fairly consistent > > with historical punch hole/discard behavior too. Hm? You might want to > > cc linux-fsdevel in future posts in any event to get some more feedback > > on how other filesystems might want to interact with such a thing. > > > Thanks for the feedback! > Argh, I completely forgot that I should add linux-fsdevel. Let me > re-send this with linux-fsdevel cc'd > > There's a slight distinction is that the current filesystem-level > controls are usually for default handling, but userspace can still > call the relevant functions manually if they need to. For example, for > ext4, the 'discard' mount option dictates whether free blocks are > discarded, but it doesn't set the policy to allow/disallow userspace > from manually punching holes into files even if the mount opt is > 'nodiscard'. FALLOC_FL_PROVISION is similar in that regard; it adds a > manual mechanism for users to provision the files' extents, that is > separate from the filesystems' default handling of provisioning files. > What I'm trying to understand is why not let blkdev_fallocate() issue a provision based on the default mode (i.e. mode == 0) of fallocate(), which is already defined to mean "perform allocation?" It currently issues discards or write zeroes based on variants of FALLOC_FL_PUNCH_HOLE without the need for a separate FALLOC_FL_DISCARD mode, for example. Brian > > BTW another thing that might be useful wrt to dm-thin is to support > > FALLOC_FL_UNSHARE. I.e., it looks like the previous dm-thin patch only > > checks that blocks are allocated, but not whether those blocks are > > shared (re: lookup_result.shared). It might be useful to do the COW in > > such cases if the caller passes down a REQ_UNSHARE or some such flag. > > > That's an interesting idea! There's a few more things on the TODO list > for this patch series but I think we can follow up with a patch to > handle that as well. > > Sarthak > > > Brian > > > > > diff --git a/include/linux/falloc.h b/include/linux/falloc.h > > > index f3f0b97b1675..a0e506255b20 100644 > > > --- a/include/linux/falloc.h > > > +++ b/include/linux/falloc.h > > > @@ -30,7 +30,8 @@ struct space_resv { > > > FALLOC_FL_COLLAPSE_RANGE | \ > > > FALLOC_FL_ZERO_RANGE | \ > > > FALLOC_FL_INSERT_RANGE | \ > > > - FALLOC_FL_UNSHARE_RANGE) > > > + FALLOC_FL_UNSHARE_RANGE | \ > > > + FALLOC_FL_PROVISION) > > > > > > /* on ia32 l_start is on a 32-bit boundary */ > > > #if defined(CONFIG_X86_64) > > > diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h > > > index 51398fa57f6c..2d323d113eed 100644 > > > --- a/include/uapi/linux/falloc.h > > > +++ b/include/uapi/linux/falloc.h > > > @@ -77,4 +77,12 @@ > > > */ > > > #define FALLOC_FL_UNSHARE_RANGE 0x40 > > > > > > +/* > > > + * FALLOC_FL_PROVISION acts as a hint for thinly provisioned devices to allocate > > > + * blocks for the range/EOF. > > > + * > > > + * FALLOC_FL_PROVISION can only be used with allocate-mode fallocate. > > > + */ > > > +#define FALLOC_FL_PROVISION 0x80 > > > + > > > #endif /* _UAPI_FALLOC_H_ */ > > > -- > > > 2.31.0 > > > > > > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel 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 0ABFDC6FA82 for ; Wed, 21 Sep 2022 15:41:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231520AbiIUPlG (ORCPT ); Wed, 21 Sep 2022 11:41:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230437AbiIUPkq (ORCPT ); Wed, 21 Sep 2022 11:40:46 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAF8E1CFD3 for ; Wed, 21 Sep 2022 08:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663774761; h=from:from:reply-to:subject:subject: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=qdyn6X4um0jOmxbVbIVJ/ritfQu0YXAwmpkbuktXlco=; b=OzEfNZuLd62HDzfMvRkXb7oOdbVBO2YJ9ii9W9Pog/v79koMxo9DQ1+YnDq08TRJu9/ok8 9Ab5i8G0J5nVXy+/UsxTgqjOolUVqKYQ9LLsYKiKifIvPeVNpIdWZIq1du3/K6XauuPC7m BSdVzhYZ3cB/1CpzyxuqOoHd275rvvA= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-421-p51WZY4BN427OjzFrqkQqg-1; Wed, 21 Sep 2022 11:39:20 -0400 X-MC-Unique: p51WZY4BN427OjzFrqkQqg-1 Received: by mail-qk1-f199.google.com with SMTP id w10-20020a05620a444a00b006ce9917ea1fso4500010qkp.16 for ; Wed, 21 Sep 2022 08:39:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=qdyn6X4um0jOmxbVbIVJ/ritfQu0YXAwmpkbuktXlco=; b=FN0iVdaRCd4ZpqXUJ9fVlCgvQAriDUB7ZOcAXW4dZML1N+jZGRYWFV5DFdA5wvi31K 4jx+y/Xtn5g+bdkI2avrca8ou0vb081ICv/NrutkyRut6EVVgV5QBZjTGuhc8alECUhm vHb2mRT5CtnKd/sA5VgHGFF4DLUC5XO9A4GCTIgQakbVfcFFVav4y7nuwezxbE6paNM6 Xl/QVo2OhDIQM0f1hfWHcS6kgZYOwh6AEwSUMoEDgXj/p79y00EwUYteoFO7TtMDzRDB qX20SRdBmPCv+zVlv84RvRGFBqafe8aglVPIuGryyxYO7qFfJUyV9Oa0w2e1GkMFWQbQ YPiA== X-Gm-Message-State: ACrzQf3OoLF+NJ/RE47m87R2xwUCDzGf/ST6ujMf/OqxuiTMy8aCyhSm ZBfOA2lYs1ZVRWWKFqfV92ughcSpUaHpaEUn7MIm7UFnFlm6o1n55LIgcolnLTKqJNoKk5QfASF AJ+1Q60ArXpwwjgElJNmteaQ= X-Received: by 2002:ac8:5a13:0:b0:35c:e9b0:430b with SMTP id n19-20020ac85a13000000b0035ce9b0430bmr13368711qta.472.1663774758899; Wed, 21 Sep 2022 08:39:18 -0700 (PDT) X-Google-Smtp-Source: AMsMyM594zwhYYo497Gbf01p/qkC0k5EzOtGiVtB6LsJU02syDsCgiXnnQXhpz8ER02eO+Lp+Qd8CQ== X-Received: by 2002:ac8:5a13:0:b0:35c:e9b0:430b with SMTP id n19-20020ac85a13000000b0035ce9b0430bmr13368681qta.472.1663774758598; Wed, 21 Sep 2022 08:39:18 -0700 (PDT) Received: from bfoster (c-24-61-119-116.hsd1.ma.comcast.net. [24.61.119.116]) by smtp.gmail.com with ESMTPSA id f25-20020ac84659000000b0035ccd148026sm1791612qto.69.2022.09.21.08.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 08:39:18 -0700 (PDT) Date: Wed, 21 Sep 2022 11:39:15 -0400 From: Brian Foster To: Sarthak Kukreti Cc: dm-devel@redhat.com, linux-block@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Jens Axboe , "Michael S . Tsirkin" , Jason Wang , Paolo Bonzini , Stefan Hajnoczi , Alasdair Kergon , Mike Snitzer , Theodore Ts'o , Andreas Dilger , Bart Van Assche , Daniil Lunev , Evan Green , Gwendal Grignou Subject: Re: [PATCH RFC 4/8] fs: Introduce FALLOC_FL_PROVISION Message-ID: References: <20220915164826.1396245-1-sarthakkukreti@google.com> <20220915164826.1396245-5-sarthakkukreti@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Fri, Sep 16, 2022 at 02:02:31PM -0700, Sarthak Kukreti wrote: > On Fri, Sep 16, 2022 at 4:56 AM Brian Foster wrote: > > > > On Thu, Sep 15, 2022 at 09:48:22AM -0700, Sarthak Kukreti wrote: > > > From: Sarthak Kukreti > > > > > > FALLOC_FL_PROVISION is a new fallocate() allocation mode that > > > sends a hint to (supported) thinly provisioned block devices to > > > allocate space for the given range of sectors via REQ_OP_PROVISION. > > > > > > Signed-off-by: Sarthak Kukreti > > > --- > > > block/fops.c | 7 ++++++- > > > include/linux/falloc.h | 3 ++- > > > include/uapi/linux/falloc.h | 8 ++++++++ > > > 3 files changed, 16 insertions(+), 2 deletions(-) > > > > > > diff --git a/block/fops.c b/block/fops.c > > > index b90742595317..a436a7596508 100644 > > > --- a/block/fops.c > > > +++ b/block/fops.c > > ... > > > @@ -661,6 +662,10 @@ static long blkdev_fallocate(struct file *file, int mode, loff_t start, > > > error = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT, > > > len >> SECTOR_SHIFT, GFP_KERNEL); > > > break; > > > + case FALLOC_FL_PROVISION: > > > + error = blkdev_issue_provision(bdev, start >> SECTOR_SHIFT, > > > + len >> SECTOR_SHIFT, GFP_KERNEL); > > > + break; > > > default: > > > error = -EOPNOTSUPP; > > > } > > > > Hi Sarthak, > > > > Neat mechanism.. I played with something very similar in the past (that > > was much more crudely hacked up to target dm-thin) to allow filesystems > > to request a thinly provisioned device to allocate blocks and try to do > > a better job of avoiding inactivation when overprovisioned. > > > > One thing I'm a little curious about here.. what's the need for a new > > fallocate mode? On a cursory glance, the provision mode looks fairly > > analogous to normal (mode == 0) allocation mode with the exception of > > sending the request down to the bdev. blkdev_fallocate() already maps > > some of the logical falloc modes (i.e. punch hole, zero range) to > > sending write sames or discards, etc., and it doesn't currently look > > like it supports allocation mode, so could it not map such requests to > > the underlying REQ_OP_PROVISION op? > > > > I guess the difference would be at the filesystem level where we'd > > probably need to rely on a mount option or some such to control whether > > traditional fallocate issues provision ops (like you've implemented for > > ext4) vs. the specific falloc command, but that seems fairly consistent > > with historical punch hole/discard behavior too. Hm? You might want to > > cc linux-fsdevel in future posts in any event to get some more feedback > > on how other filesystems might want to interact with such a thing. > > > Thanks for the feedback! > Argh, I completely forgot that I should add linux-fsdevel. Let me > re-send this with linux-fsdevel cc'd > > There's a slight distinction is that the current filesystem-level > controls are usually for default handling, but userspace can still > call the relevant functions manually if they need to. For example, for > ext4, the 'discard' mount option dictates whether free blocks are > discarded, but it doesn't set the policy to allow/disallow userspace > from manually punching holes into files even if the mount opt is > 'nodiscard'. FALLOC_FL_PROVISION is similar in that regard; it adds a > manual mechanism for users to provision the files' extents, that is > separate from the filesystems' default handling of provisioning files. > What I'm trying to understand is why not let blkdev_fallocate() issue a provision based on the default mode (i.e. mode == 0) of fallocate(), which is already defined to mean "perform allocation?" It currently issues discards or write zeroes based on variants of FALLOC_FL_PUNCH_HOLE without the need for a separate FALLOC_FL_DISCARD mode, for example. Brian > > BTW another thing that might be useful wrt to dm-thin is to support > > FALLOC_FL_UNSHARE. I.e., it looks like the previous dm-thin patch only > > checks that blocks are allocated, but not whether those blocks are > > shared (re: lookup_result.shared). It might be useful to do the COW in > > such cases if the caller passes down a REQ_UNSHARE or some such flag. > > > That's an interesting idea! There's a few more things on the TODO list > for this patch series but I think we can follow up with a patch to > handle that as well. > > Sarthak > > > Brian > > > > > diff --git a/include/linux/falloc.h b/include/linux/falloc.h > > > index f3f0b97b1675..a0e506255b20 100644 > > > --- a/include/linux/falloc.h > > > +++ b/include/linux/falloc.h > > > @@ -30,7 +30,8 @@ struct space_resv { > > > FALLOC_FL_COLLAPSE_RANGE | \ > > > FALLOC_FL_ZERO_RANGE | \ > > > FALLOC_FL_INSERT_RANGE | \ > > > - FALLOC_FL_UNSHARE_RANGE) > > > + FALLOC_FL_UNSHARE_RANGE | \ > > > + FALLOC_FL_PROVISION) > > > > > > /* on ia32 l_start is on a 32-bit boundary */ > > > #if defined(CONFIG_X86_64) > > > diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h > > > index 51398fa57f6c..2d323d113eed 100644 > > > --- a/include/uapi/linux/falloc.h > > > +++ b/include/uapi/linux/falloc.h > > > @@ -77,4 +77,12 @@ > > > */ > > > #define FALLOC_FL_UNSHARE_RANGE 0x40 > > > > > > +/* > > > + * FALLOC_FL_PROVISION acts as a hint for thinly provisioned devices to allocate > > > + * blocks for the range/EOF. > > > + * > > > + * FALLOC_FL_PROVISION can only be used with allocate-mode fallocate. > > > + */ > > > +#define FALLOC_FL_PROVISION 0x80 > > > + > > > #endif /* _UAPI_FALLOC_H_ */ > > > -- > > > 2.31.0 > > > > > > 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 smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 8B589C6FA82 for ; Wed, 21 Sep 2022 15:39:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 0A31E416E7; Wed, 21 Sep 2022 15:39:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0A31E416E7 Authentication-Results: smtp4.osuosl.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ZkcvuyuK X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDPvZG56BX63; Wed, 21 Sep 2022 15:39:27 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id ED6E9402C3; Wed, 21 Sep 2022 15:39:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org ED6E9402C3 Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B8958C0033; Wed, 21 Sep 2022 15:39:26 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 68A22C002D for ; Wed, 21 Sep 2022 15:39:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 41843402C3 for ; Wed, 21 Sep 2022 15:39:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 41843402C3 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc8szqvUkXEz for ; Wed, 21 Sep 2022 15:39:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C1BF0416D2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp4.osuosl.org (Postfix) with ESMTPS id C1BF0416D2 for ; Wed, 21 Sep 2022 15:39:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663774762; h=from:from:reply-to:subject:subject: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=qdyn6X4um0jOmxbVbIVJ/ritfQu0YXAwmpkbuktXlco=; b=ZkcvuyuKtZceBatTwuQsg+6//1H7l8u2DReMGM9wx4E2Q+HXIRb6aNQ8TIVolZWBLBiDoK hXJp5/3LFfvHtxd68v1IOlHDx6vjsXPNNFVwRtj19BdYlny/p8WSUOilpTbhMEPXUYCHD2 3NC/uZ7xCGZSLTI3FnJfASNPDyL7ArU= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-75-AxvzVXQjO56nJ5LzXGl9dQ-1; Wed, 21 Sep 2022 11:39:19 -0400 X-MC-Unique: AxvzVXQjO56nJ5LzXGl9dQ-1 Received: by mail-qv1-f70.google.com with SMTP id c1-20020a0cfb01000000b00495ad218c74so4575369qvp.20 for ; Wed, 21 Sep 2022 08:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=qdyn6X4um0jOmxbVbIVJ/ritfQu0YXAwmpkbuktXlco=; b=Jqnt0IKFstPPOdUg/oB4B4k2B38bM+LjWf+TtVUOovvUwQa4BLPeHQo35FCpDEmEsv B21bgRWzvvU3VXxSup8N+Hdtt2bNxL9vVqfKL+xVisb6rHbd6wzQoEezE4zTIgkDwZyC IWQ9MvUZxgnWm3RFMxW7pmscgRLMnNQIXXB/1/dlm00oCjYw2lumwQgu8hZ8gDixbrzw z0mfs6hC1R4vqod1zki7RITghcfPiVEEFIOWpsT//H2g6yGi5whap7M/b/klpS9Wf2DC +Qg2RUdJlGvr1osnGAxAafHOFQ8NuwQJzxm+yTVz2KGoKhLAQm4t55XMZp0Smp7P6KvB c7Fw== X-Gm-Message-State: ACrzQf2afrihbOLopjTtNTiX3WGjVcU3PcgKHlEGrQzhzborbC9NhuJ5 wBwrHhPX8F1x6SviztIy5qk3GeIyFSuMWcQd5P2KRKTTdGAUWd+9VMeLm8EYyt8M3qvtilSp3JQ 5agnwkxQNwmpvAqc9lii2WoJNZdLzZO64NPYhrAw+6A== X-Received: by 2002:ac8:5a13:0:b0:35c:e9b0:430b with SMTP id n19-20020ac85a13000000b0035ce9b0430bmr13368708qta.472.1663774758897; Wed, 21 Sep 2022 08:39:18 -0700 (PDT) X-Google-Smtp-Source: AMsMyM594zwhYYo497Gbf01p/qkC0k5EzOtGiVtB6LsJU02syDsCgiXnnQXhpz8ER02eO+Lp+Qd8CQ== X-Received: by 2002:ac8:5a13:0:b0:35c:e9b0:430b with SMTP id n19-20020ac85a13000000b0035ce9b0430bmr13368681qta.472.1663774758598; Wed, 21 Sep 2022 08:39:18 -0700 (PDT) Received: from bfoster (c-24-61-119-116.hsd1.ma.comcast.net. [24.61.119.116]) by smtp.gmail.com with ESMTPSA id f25-20020ac84659000000b0035ccd148026sm1791612qto.69.2022.09.21.08.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 08:39:18 -0700 (PDT) Date: Wed, 21 Sep 2022 11:39:15 -0400 From: Brian Foster To: Sarthak Kukreti Subject: Re: [PATCH RFC 4/8] fs: Introduce FALLOC_FL_PROVISION Message-ID: References: <20220915164826.1396245-1-sarthakkukreti@google.com> <20220915164826.1396245-5-sarthakkukreti@google.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Cc: Jens Axboe , Gwendal Grignou , Theodore Ts'o , "Michael S . Tsirkin" , Bart Van Assche , Mike Snitzer , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-block@vger.kernel.org, dm-devel@redhat.com, Andreas Dilger , Daniil Lunev , Stefan Hajnoczi , Paolo Bonzini , linux-ext4@vger.kernel.org, Evan Green , Alasdair Kergon X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Fri, Sep 16, 2022 at 02:02:31PM -0700, Sarthak Kukreti wrote: > On Fri, Sep 16, 2022 at 4:56 AM Brian Foster wrote: > > > > On Thu, Sep 15, 2022 at 09:48:22AM -0700, Sarthak Kukreti wrote: > > > From: Sarthak Kukreti > > > > > > FALLOC_FL_PROVISION is a new fallocate() allocation mode that > > > sends a hint to (supported) thinly provisioned block devices to > > > allocate space for the given range of sectors via REQ_OP_PROVISION. > > > > > > Signed-off-by: Sarthak Kukreti > > > --- > > > block/fops.c | 7 ++++++- > > > include/linux/falloc.h | 3 ++- > > > include/uapi/linux/falloc.h | 8 ++++++++ > > > 3 files changed, 16 insertions(+), 2 deletions(-) > > > > > > diff --git a/block/fops.c b/block/fops.c > > > index b90742595317..a436a7596508 100644 > > > --- a/block/fops.c > > > +++ b/block/fops.c > > ... > > > @@ -661,6 +662,10 @@ static long blkdev_fallocate(struct file *file, int mode, loff_t start, > > > error = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT, > > > len >> SECTOR_SHIFT, GFP_KERNEL); > > > break; > > > + case FALLOC_FL_PROVISION: > > > + error = blkdev_issue_provision(bdev, start >> SECTOR_SHIFT, > > > + len >> SECTOR_SHIFT, GFP_KERNEL); > > > + break; > > > default: > > > error = -EOPNOTSUPP; > > > } > > > > Hi Sarthak, > > > > Neat mechanism.. I played with something very similar in the past (that > > was much more crudely hacked up to target dm-thin) to allow filesystems > > to request a thinly provisioned device to allocate blocks and try to do > > a better job of avoiding inactivation when overprovisioned. > > > > One thing I'm a little curious about here.. what's the need for a new > > fallocate mode? On a cursory glance, the provision mode looks fairly > > analogous to normal (mode == 0) allocation mode with the exception of > > sending the request down to the bdev. blkdev_fallocate() already maps > > some of the logical falloc modes (i.e. punch hole, zero range) to > > sending write sames or discards, etc., and it doesn't currently look > > like it supports allocation mode, so could it not map such requests to > > the underlying REQ_OP_PROVISION op? > > > > I guess the difference would be at the filesystem level where we'd > > probably need to rely on a mount option or some such to control whether > > traditional fallocate issues provision ops (like you've implemented for > > ext4) vs. the specific falloc command, but that seems fairly consistent > > with historical punch hole/discard behavior too. Hm? You might want to > > cc linux-fsdevel in future posts in any event to get some more feedback > > on how other filesystems might want to interact with such a thing. > > > Thanks for the feedback! > Argh, I completely forgot that I should add linux-fsdevel. Let me > re-send this with linux-fsdevel cc'd > > There's a slight distinction is that the current filesystem-level > controls are usually for default handling, but userspace can still > call the relevant functions manually if they need to. For example, for > ext4, the 'discard' mount option dictates whether free blocks are > discarded, but it doesn't set the policy to allow/disallow userspace > from manually punching holes into files even if the mount opt is > 'nodiscard'. FALLOC_FL_PROVISION is similar in that regard; it adds a > manual mechanism for users to provision the files' extents, that is > separate from the filesystems' default handling of provisioning files. > What I'm trying to understand is why not let blkdev_fallocate() issue a provision based on the default mode (i.e. mode == 0) of fallocate(), which is already defined to mean "perform allocation?" It currently issues discards or write zeroes based on variants of FALLOC_FL_PUNCH_HOLE without the need for a separate FALLOC_FL_DISCARD mode, for example. Brian > > BTW another thing that might be useful wrt to dm-thin is to support > > FALLOC_FL_UNSHARE. I.e., it looks like the previous dm-thin patch only > > checks that blocks are allocated, but not whether those blocks are > > shared (re: lookup_result.shared). It might be useful to do the COW in > > such cases if the caller passes down a REQ_UNSHARE or some such flag. > > > That's an interesting idea! There's a few more things on the TODO list > for this patch series but I think we can follow up with a patch to > handle that as well. > > Sarthak > > > Brian > > > > > diff --git a/include/linux/falloc.h b/include/linux/falloc.h > > > index f3f0b97b1675..a0e506255b20 100644 > > > --- a/include/linux/falloc.h > > > +++ b/include/linux/falloc.h > > > @@ -30,7 +30,8 @@ struct space_resv { > > > FALLOC_FL_COLLAPSE_RANGE | \ > > > FALLOC_FL_ZERO_RANGE | \ > > > FALLOC_FL_INSERT_RANGE | \ > > > - FALLOC_FL_UNSHARE_RANGE) > > > + FALLOC_FL_UNSHARE_RANGE | \ > > > + FALLOC_FL_PROVISION) > > > > > > /* on ia32 l_start is on a 32-bit boundary */ > > > #if defined(CONFIG_X86_64) > > > diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h > > > index 51398fa57f6c..2d323d113eed 100644 > > > --- a/include/uapi/linux/falloc.h > > > +++ b/include/uapi/linux/falloc.h > > > @@ -77,4 +77,12 @@ > > > */ > > > #define FALLOC_FL_UNSHARE_RANGE 0x40 > > > > > > +/* > > > + * FALLOC_FL_PROVISION acts as a hint for thinly provisioned devices to allocate > > > + * blocks for the range/EOF. > > > + * > > > + * FALLOC_FL_PROVISION can only be used with allocate-mode fallocate. > > > + */ > > > +#define FALLOC_FL_PROVISION 0x80 > > > + > > > #endif /* _UAPI_FALLOC_H_ */ > > > -- > > > 2.31.0 > > > > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization