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 C2590C54EE9 for ; Tue, 20 Sep 2022 07:50:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230100AbiITHuk (ORCPT ); Tue, 20 Sep 2022 03:50:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229926AbiITHt7 (ORCPT ); Tue, 20 Sep 2022 03:49:59 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEDB9219D; Tue, 20 Sep 2022 00:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=AU0mZCMIx8JARy0byW2BmRzgYXSYzSXxAhWcU08IaqY=; b=aUezXLcVpUDpj+rBGwR2e2Dq+j +m8n/y4046APNRMEDTF0ZqaDkAxglTlVUNTJr9E1Z6iC226V1Bog1WEQ2+K4ikDCcQlgIfO79QYEn goQtBRPP+NXjgTSijBjOyUanFbCeVbhd0zVD0jL5AzO3eoXRAf7sgibPwBwjIJpBRSuo6MlMOJVkH 45Z1TPzd/6ND3EgH8tHfjOOybk9MqFcjdvPfa8IIrKATJFRTJJ/ua6OyNsUaM6kt5wiagvMuJ7Cav WHJ9MvPeN6mIa0F7Nz1cmXZ0IlQ7xW2U8RmCkN9IPpyqtDS+bJksjLZ3l0EsO/cbt4ePE8hMqOnbn EqnTWtdQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1oaY0H-001Ung-4F; Tue, 20 Sep 2022 07:49:13 +0000 Date: Tue, 20 Sep 2022 00:49:13 -0700 From: Christoph Hellwig 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: <20220915164826.1396245-5-sarthakkukreti@google.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. So, how does that "provisioning" actually work in todays world where storage is usually doing out of place writes in one or more layers, including the flash storage everyone is using. Does it give you one write? And unlimited number? Some undecided number inbetween? How is it affected by write zeroes to that range or a discard?