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 X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D980C2BA83 for ; Thu, 13 Feb 2020 06:51:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 45F592173E for ; Thu, 13 Feb 2020 06:51:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729383AbgBMGvf (ORCPT ); Thu, 13 Feb 2020 01:51:35 -0500 Received: from len.romanrm.net ([91.121.86.59]:51060 "EHLO len.romanrm.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726654AbgBMGvf (ORCPT ); Thu, 13 Feb 2020 01:51:35 -0500 Received: from natsu (natsu.40.romanrm.net [IPv6:fd39:aa:c499:6515:e99e:8f1b:cfc9:ccb8]) by len.romanrm.net (Postfix) with SMTP id 15A2340300; Thu, 13 Feb 2020 06:51:33 +0000 (UTC) Date: Thu, 13 Feb 2020 11:51:33 +0500 From: Roman Mamedov To: Chris Murphy Cc: Btrfs BTRFS Subject: Re: fstrim reports different value 1 minute later Message-ID: <20200213115133.6a109d69@natsu> In-Reply-To: References: <20200213112110.7100baf2@natsu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, 12 Feb 2020 23:37:26 -0700 Chris Murphy wrote: > I have fstrim.timer set to run fstrim.service once per week, and that > reports sane (expected) values each time. But, it also tends to happen > soon after a fresh boot or wake from S3. I believe Btrfs now[1] tracks which areas have been trimmed already during the current mount and does not re-trim them again, like ext4 does since a long time ago. In case of ext4, for your scenario the first trim would return 91GB, and the subsequent ones (assuming no FS activity) would trim 0 bytes. But if the above is indeed the cause, then I'm not sure why it still always retrims about 3.6 GB or 11 GB for your other machine, even with no writes or deletions. [1] https://patchwork.kernel.org/patch/11254859/ -- With respect, Roman