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 B86E4C433EF for ; Sat, 23 Jul 2022 19:26:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234236AbiGWT0i (ORCPT ); Sat, 23 Jul 2022 15:26:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbiGWT0g (ORCPT ); Sat, 23 Jul 2022 15:26:36 -0400 Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81F5813D66 for ; Sat, 23 Jul 2022 12:26:35 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id DA982580995; Sat, 23 Jul 2022 15:26:34 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute3.internal (MEProxy); Sat, 23 Jul 2022 15:26:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= colorremedies.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1658604394; x= 1658607994; bh=lQBTQN0LivR3KR7+m26xL0L9xIO/4ipIglRlP8mZ8VA=; b=V qrYS//iGclp/7EIKHp+8Lz0ba5h4W2TCiIoSZu/WiszXEslZ9k4WpJGjO25ELmXP hkbb1N/WW52XTEXAYqdx0wpl/UQV6/vr06hEGnasgUW6xPPUkM6RxRWpqclK29Ra ome/CEfp3yacThtAiFSrWpEd1TleIcC5/tx/9HEgbF9AxKI2Eiazx/P5EUBumgLX FMmP+AbYwXXc21YnIYxdV3vJ8V6/Xf9Z4/oTFzvm7CpI4JKmDzC76o9Nw2GjqyME Frb0WmJOBoqgoxhoi327wcsgzdyLblf7gf0x4dslm8ZYwiGMaIulOU1z3HoKfWYH 1VRNpAQUf/25wLDLXgPGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= i06494636.fm3; t=1658604394; x=1658607994; bh=lQBTQN0LivR3KR7+m2 6xL0L9xIO/4ipIglRlP8mZ8VA=; b=ihMPMIWUuWGBIk2eFoipYHIKE6iJnSL2CN BShhwYP1se9A+WVVKzFvN/i4BJpdotuBr/VlATBGLzhmfQ9ogjg9IjfyNNB08VjY UXozu9AXN+tp98xNomDa9r8w9v6G3eFEXhBbiqJgeiH62Lfx/PxzXQmBaeP+VmLa F3mQDt363GtWuYoJjR77AXclMH4rbbHv7Sb3NRjMK1qGsYGEz4ri2fRCjpukbS9B 0PjsDkMDAmfhbaEEaTGrWGI2zR1AhjP8VfGm2ckVmlADHVYpekLgMDDVqSzC2M6p SMfE1nb0EkVS2PFvN4lXCZCgi2/0GpQqids3bt7znVcPvT/NUm9Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvddtgedgudegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdev hhhrihhsucfouhhrphhhhidfuceolhhishhtshestgholhhorhhrvghmvgguihgvshdrtg homheqnecuggftrfgrthhtvghrnhepgfdvueektdefgfefgfdtleffvdeileetgfefuddt ffelueeiveeiveekhedtheeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheplhhishhtshestgholhhorhhrvghmvgguihgvshdrtghomh X-ME-Proxy: Feedback-ID: i06494636:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6CE191700082; Sat, 23 Jul 2022 15:26:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-757-gc3ad9c75d3-fm-20220722.001-gc3ad9c75 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9bdd0eb6-4a4f-e168-0fb0-77f4d753ec19@gmail.com> <4263e65e-f585-e7f6-b1aa-04885c0ed662@gmail.com> <042e75ab-ded2-009a-d9fc-95887c26d4d2@libero.it> Date: Sat, 23 Jul 2022 15:26:13 -0400 From: "Chris Murphy" To: "Zygo Blaxell" , "Goffredo Baroncelli" Cc: "Boris Burkov" , "Apostolos B." , "Btrfs BTRFS" , "systemd List" Subject: Re: No space left errors on shutdown with systemd-homed /home dir Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, Jan 31, 2022, at 11:26 PM, Zygo Blaxell wrote: > On Sat, Jan 29, 2022 at 10:53:00AM +0100, Goffredo Baroncelli wrote: > It does suck that the kernel handles resizing below the minimum size of > the filesystem so badly; however, even if it rejected the resize request > cleanly with an error, it's not necessarily a good idea to attempt it. > Pushing the lower limits of what is possible in resize to save a handful > of GB is asking for trouble. It's far better to overestimate generously > than to underestimate the minimum size. Yeah there's an inherent conflict with online shrink: the longer the time needed to relocate bg's, the more unpredictable operations can occur during that time to thwart any original estimations made about the shrink operation. I wondered a bit ago about a shrink API that takes shrink size as a suggestion rather than as a definite, and then the file system does the best job it can. Either this API reports actual shrink size once it completes, or the requesting program needs to know to call BTRFS_IOC_FS_INFO and BTRFS_IOC_DEV_INFO to know the actual size. This hypothetical API could have boundaries outside of which if the kernel code estimates it's going to fall short of, could trigger a cancel of the shrink. This could be size or time based. e.g. BTRFS_IOC_RESIZE_BEST (effort). -- Chris Murphy