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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0052AC433EF for ; Fri, 26 Nov 2021 07:51:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 296026B0075; Fri, 26 Nov 2021 02:51:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 245796B0078; Fri, 26 Nov 2021 02:51:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 134256B007B; Fri, 26 Nov 2021 02:51:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id 0330C6B0075 for ; Fri, 26 Nov 2021 02:51:22 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AB75A80F3D01 for ; Fri, 26 Nov 2021 07:51:11 +0000 (UTC) X-FDA: 78850310784.14.7A3EB01 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 27163F0000AC for ; Fri, 26 Nov 2021 07:51:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637913070; 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; bh=pKrBdACVIJnw8UTyT2VosD/1qF59jead3LdbchpARS0=; b=SQsx5VGeakjfeyByuI5AB9+G1Bc4bsp2UA/nLWEHs+VETV/RU/kzoKHXDx7FfKisZr/84m vuvExqJg54gFLhCJZg7LiSaTajRDqILiDQeXlhCxUsI3rbV702One31X6s/51YE5ZM/0Dp BEWWFw6+TvYDWmEe/cY6zykEK5Kscic= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-330-vl-rd88cMjCx-PcJSkGtmA-1; Fri, 26 Nov 2021 02:51:07 -0500 X-MC-Unique: vl-rd88cMjCx-PcJSkGtmA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 05415363A6; Fri, 26 Nov 2021 07:51:06 +0000 (UTC) Received: from work (unknown [10.40.192.244]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0DD9D4ABA2; Fri, 26 Nov 2021 07:51:04 +0000 (UTC) Date: Fri, 26 Nov 2021 08:51:00 +0100 From: Lukas Czerner To: hughd@google.com, linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org Subject: unusual behavior of loop dev with backing file in tmpfs Message-ID: <20211126075100.gd64odg2bcptiqeb@work> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 27163F0000AC X-Stat-Signature: h8nwz3speg4a8bxow8nee5mauychj8bh Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SQsx5VGe; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf11.hostedemail.com: domain of lczerner@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=lczerner@redhat.com X-HE-Tag: 1637913070-166020 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, I've noticed unusual test failure in e2fsprogs testsuite (m_assume_storage_prezeroed) where we use mke2fs to create a file system on loop device backed in file on tmpfs. For some reason sometimes the resulting file number of allocated blocks (stat -c '%b' /tmp/file) differs, but it really should not. I was trying to create a simplified reproducer and noticed the following behavior on mainline kernel (v5.16-rc2-54-g5d9f4cf36721) # truncate -s16M /tmp/file # stat -c '%b' /tmp/file 0 # losetup -f /tmp/file # stat -c '%b' /tmp/file 672 That alone is a little unexpected since the file is really supposed to be empty and when copied out of the tmpfs, it really is empty. But the following is even more weird. We have a loop setup from above, so let's assume it's /dev/loop0. The following should be executed in quick succession, like in a script. # dd if=/dev/zero of=/dev/loop0 bs=4k # blkdiscard -f /dev/loop0 # stat -c '%b' /tmp/file 0 # sleep 1 # stat -c '%b' /tmp/file 672 Is that expected behavior ? From what I've seen when I use mkfs instead of this simplified example the number of blocks allocated as reported by stat can vary a quite a lot given more complex operations. The file itself does not seem to be corrupted in any way, so it is likely just an accounting problem. Any idea what is going on there ? Thanks! -Lukas