Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1202652pxu; Wed, 6 Jan 2021 15:41:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJznNa/s7KuZDMstKWsz4J+3jBWWgYgzagiuCB2lx7Ftk21L0SbAhjw9gbw4jzDIk7pr+tr7 X-Received: by 2002:a17:906:aeda:: with SMTP id me26mr4444093ejb.11.1609976516724; Wed, 06 Jan 2021 15:41:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609976516; cv=none; d=google.com; s=arc-20160816; b=TJeLg6fA0KGdbKMPrm4D9lwiQS4qXFZzBaZQNAkSTczIaU7qLfyl/uPztXKUy6jt8G VQcP5Sc00ddw8T1vRgnScQZa7CIhU+io/9Q3YMmjOooQxnHQReg25CptdbmHRfsoKK5M OihMBgREUpNRfiHEv/kcq2+4/jOYH4G2RfH8PSgT1UN5CLxIRlw/oi3Y7A35iHnQdefi RmGceYTio4kL6wGyPMix3SQwKIvxKQ3S5WK3yNovrYJueXh0efKW7XZ8pyf0bAyeYKjw b5fxefbwCfUCIROvhW0OFQkzjHmRFtXjikQgHU+4gOHT5uj84Y6DIkk9YE0B68KUX0Z8 yBCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=n5SmyEUKkQ7qERAis2ZaaktUbKh4cYFmBEpwHyqlAFw=; b=OmJL9wUT81aFhIbd3ejx7LRHFQuNYNGHL90ozhjuiJxDmkjD0phC25NwjPMoQR9tBx vPqZsBu9R0kqvv/bZVHJo7ptEsnAGr2biY/fugrDMq+NLBTKep3nUilONQJfRbB6JEdz qWJGvxhuRoI0HqspuT+g9Ae9B01u/FAMUxl+Hl/InJY6BId4STwkVxKAYggjvyKpoyxS 9OOX7aY8MR1jQF/9hzm/0AX0mi/GOO3uG40GYIwNN+bBaqpEzc9RThHv1MZQP9zcofYB MNGWOlAX0o9qUUNKHM1DHmq7UKSr9lck/1glp03RHqhFGv9cdYCtMSjrdcmplcLFeGvV 5AdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@anarazel.de header.s=fm3 header.b=kHvX0HT4; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=iv1IZft2; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ak15si1465096ejc.654.2021.01.06.15.41.32; Wed, 06 Jan 2021 15:41:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@anarazel.de header.s=fm3 header.b=kHvX0HT4; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=iv1IZft2; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727098AbhAFXlS (ORCPT + 99 others); Wed, 6 Jan 2021 18:41:18 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:60437 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726918AbhAFXlS (ORCPT ); Wed, 6 Jan 2021 18:41:18 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D05FD14B3; Wed, 6 Jan 2021 18:40:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 06 Jan 2021 18:40:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=n5SmyEUKkQ7qERAis2ZaaktUbKh 4cYFmBEpwHyqlAFw=; b=kHvX0HT4JwMXX9ZXBdMY6+ppwTMBzcFa/noS3E7R7LA rIEt2BYOivw6sm3TvMXh+/Su+B8gBZMuZnASFMWzh8CmH22/QobA/cdaNoM0Nvz2 WrR6kioaEU8vWLJpvk1bSddNc5adfWk25W+pia9dEfAofzNmZQTl+ySh+Ck6w9Gx yqYPkUzKIIBfB+C2M1V02ttRPH5RqstR2MkR/JQ6lqFkHVf/hCvOOy6aMou4GqAx zXq4kUC5/dqidzy7OVa1GmUV5mjLIkNTm2PigQXdL2HhN1nYLNNSM2kAKE6c0qpW mZKNSgMOQiEHpKRHthNbgzv/MnMFsTgRS0O1oIvziXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=n5SmyE UKkQ7qERAis2ZaaktUbKh4cYFmBEpwHyqlAFw=; b=iv1IZft2dhtPMs6a0ZYLDL KhOC4nlPgNHnErGjdxhRWfrhWZOdvDZEM/YDFhWN4kcj74JcIH/LDiHSnkj7QZNg lMo5531yhZtV5wMdF0IyZSlif3ag33JCBPd4PlVTh7Piy6wgR2O7rCMzygyHYA1z YM3d4ZTjFMaONAvrHVAtyRXicMBy9fw7T0E/X79MpoIKUBdl+JTVr7KNwL1Rng9e Vof3W1Z9xZPj18gBRFU/4xqIFotwytro4qstNBfbeK4DFgORHNIgs/sPIBso3fz1 jtPIF7CQGePsQ+TuSHhmY/ENvb6iRA+y9K4AjMiJuk7iojg6egRUe0L+5RpZ90/g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegtddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomheptehnughrvghsucfhrhgvuhhnugcuoegrnhgurhgvshesrghn rghrrgiivghlrdguvgeqnecuggftrfgrthhtvghrnhepudekhfekleeugeevteehleffff ejgeelueduleeffeeutdelffeujeffhfeuffdunecukfhppeeijedrudeitddrvddujedr vdehtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Received: from intern.anarazel.de (c-67-160-217-250.hsd1.ca.comcast.net [67.160.217.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EE18240064; Wed, 6 Jan 2021 18:40:11 -0500 (EST) Date: Wed, 6 Jan 2021 15:40:09 -0800 From: Andres Freund To: Dave Chinner Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-block@vger.kernel.org Subject: Re: fallocate(FALLOC_FL_ZERO_RANGE_BUT_REALLY) to avoid unwritten extents? Message-ID: <20210106234009.b6gbzl7bjm2evxj6@alap3.anarazel.de> References: <20201230062819.yinrrp6uwfegsqo3@alap3.anarazel.de> <20210106225201.GF331610@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210106225201.GF331610@dread.disaster.area> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi, On 2021-01-07 09:52:01 +1100, Dave Chinner wrote: > On Tue, Dec 29, 2020 at 10:28:19PM -0800, Andres Freund wrote: > > Which brings me to $subject: > > > > Would it make sense to add a variant of FALLOC_FL_ZERO_RANGE that > > doesn't convert extents into unwritten extents, but instead uses > > blkdev_issue_zeroout() if supported? Mostly interested in xfs/ext4 > > myself, but ... > > We have explicit requests from users (think initialising large VM > images) that FALLOC_FL_ZERO_RANGE must never fall back to writing > zeroes manually. That behaviour makes a lot of sense for quite a few use cases - I wasn't trying to make it sound like it should not be available. Nor that FALLOC_FL_ZERO_RANGE should behave differently. > IOWs, while you might want FALLOC_FL_ZERO_RANGE to explicitly write > zeros, we have users who explicitly don't want it to do this. Right - which is why I was asking for a variant of FALLOC_FL_ZERO_RANGE (jokingly named FALLOC_FL_ZERO_RANGE_BUT_REALLY in the subject), rather than changing the behaviour. > Perhaps we should add want FALLOC_FL_CONVERT_RANGE, which tells the > filesystem to convert an unwritten range of zeros to a written range > by manually writing zeros. i.e. you do FALLOC_FL_ZERO_RANGE to zero > the range and fill holes using metadata manipulation, followed by > FALLOC_FL_WRITE_RANGE to then convert the "metadata zeros" to real > written zeros. Yep, something like that would do the trick. Perhaps FALLOC_FL_MATERIALIZE_RANGE? Greetings, Andres Freund