Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/1.1/patches/2229472/?format=api
{ "id": 2229472, "url": "http://patchwork.ozlabs.org/api/1.1/patches/2229472/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/patch/20260428085750.1072612-1-yi.zhang@huaweicloud.com/", "project": { "id": 8, "url": "http://patchwork.ozlabs.org/api/1.1/projects/8/?format=api", "name": "Linux ext4 filesystem development", "link_name": "linux-ext4", "list_id": "linux-ext4.vger.kernel.org", "list_email": "linux-ext4@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null }, "msgid": "<20260428085750.1072612-1-yi.zhang@huaweicloud.com>", "date": "2026-04-28T08:57:50", "name": "[v3] generic/790: test post-EOF gap zeroing persistence", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "290d2ff3f2a653bfb4e982784bf6e5070762ede9", "submitter": { "id": 85428, "url": "http://patchwork.ozlabs.org/api/1.1/people/85428/?format=api", "name": "Zhang Yi", "email": "yi.zhang@huaweicloud.com" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/linux-ext4/patch/20260428085750.1072612-1-yi.zhang@huaweicloud.com/mbox/", "series": [ { "id": 501808, "url": "http://patchwork.ozlabs.org/api/1.1/series/501808/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/list/?series=501808", "date": "2026-04-28T08:57:50", "name": "[v3] generic/790: test post-EOF gap zeroing persistence", "version": 3, "mbox": "http://patchwork.ozlabs.org/series/501808/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2229472/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2229472/checks/", "tags": {}, "headers": { "Return-Path": "\n <SRS0=Fexo=C3=vger.kernel.org=linux-ext4+bounces-16169-patchwork-incoming=ozlabs.org@ozlabs.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-ext4@vger.kernel.org" ], "Delivered-To": [ "patchwork-incoming@legolas.ozlabs.org", "patchwork-incoming@ozlabs.org" ], "Authentication-Results": [ "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=150.107.74.76; helo=mail.ozlabs.org;\n envelope-from=srs0=fexo=c3=vger.kernel.org=linux-ext4+bounces-16169-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)", "gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=172.234.253.10 arc.chain=subspace.kernel.org", "gandalf.ozlabs.org;\n dmarc=none (p=none dis=none) header.from=huaweicloud.com", "gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-16169-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)", "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=45.249.212.51", "smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=huaweicloud.com", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=huaweicloud.com" ], "Received": [ "from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g4bGv5kLwz1yHX\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 28 Apr 2026 19:48:39 +1000 (AEST)", "from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4g4bGv3s71z4wH2\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 28 Apr 2026 19:48:39 +1000 (AEST)", "by gandalf.ozlabs.org (Postfix)\n\tid 4g4bGv3n7Bz4wCx; Tue, 28 Apr 2026 19:48:39 +1000 (AEST)", "from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4g4bGr1JR8z4wH2\n\tfor <patchwork-incoming@ozlabs.org>; Tue, 28 Apr 2026 19:48:36 +1000 (AEST)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 0C985339263D\n\tfor <patchwork-incoming@ozlabs.org>; Tue, 28 Apr 2026 09:07:47 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id EDB413D9DC0;\n\tTue, 28 Apr 2026 09:04:40 +0000 (UTC)", "from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com\n [45.249.212.51])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 74EFD37E2E5;\n\tTue, 28 Apr 2026 09:04:34 +0000 (UTC)", "from mail.maildlp.com (unknown [172.19.163.177])\n\tby dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4g4ZHk2c37zYQtxh;\n\tTue, 28 Apr 2026 17:04:18 +0800 (CST)", "from mail02.huawei.com (unknown [10.116.40.128])\n\tby mail.maildlp.com (Postfix) with ESMTP id 0586540592;\n\tTue, 28 Apr 2026 17:04:25 +0800 (CST)", "from huaweicloud.com (unknown [10.50.85.155])\n\tby APP4 (Coremail) with SMTP id gCh0CgBHD1sQePBp2ZtgAQ--.9895S4;\n\tTue, 28 Apr 2026 17:04:24 +0800 (CST)" ], "ARC-Seal": [ "i=2; a=rsa-sha256; d=ozlabs.org; s=201707; t=1777369719; cv=pass;\n\tb=cE3AJr4lp10X7Z2t/0wEEqbbX/He0tdWd+Y444GGh9VN66HTcdTvkcfSryocDbM2+ztL4I8afsX76Thg7BSZuo5fgB1T9P4/L1cKPpf/iGe1eVkXzSRBLCcBs540HEnSdhUB4Rys20HSV9gsXDKkUZaiC/9nKnXWHz1fLQP+QfAp8nuFr2e5iaLnNYV+OHjDjEognVfVwki0Sa7Ze2uG/+un3CPmRPMlwNpBekh55OzyYDM/VFYVSuMRYw2lh/klj/6ADiqEgXnz1oxxAok2jjHtroHwq9e4iGO1NlHhAc6f/uM3sN/eO1unqIdQR21Ty9wShvslIo7/B/V5q3vI4Q==", "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777367080; cv=none;\n b=UuW2FkB7wGCTNYmDyNRL3qjOXvuNgfzo9NgLDj6BQ7oiBNxvc96zEI0L98SYZ6H/OMOTZbTmkM1Mphi5KOFBadvG6xULq0EHn6T4BAS1zizyLRdPR7gt+O22IIq2Y/VKQxoXvQTR2/Zhk6xVFQGJ6XD+KFxXSAiFM1VZW6RrHzI=" ], "ARC-Message-Signature": [ "i=2; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1777369719; c=relaxed/relaxed;\n\tbh=cfHoFVcPRBQcrPXDg1vXpoBgjeFCaZloFiXZkWEzJyA=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version;\n b=P0zz+59ofluCj/1k1/JefNUtNGmyknuAAU/kfo0q7JXFX2g0n1CBNryIp9lgDgQf+klEO0d8CrvUepBF3phUyFc7fxCQwUCvSQ067Hpx6LCogRhq1P0SA+wL5WMQfmVfaP4LOgkKsev7TIYCpHsUA/IRZUN6NMzxK3HQ8aSXSKsIeRokU+WhGGKGlZ+Ku7X9Kh2CGzS6htJBYNF42QkNxyP15TIFR2UKL31Z0eyXzJnX/DUxXkjbg5OalJbmVO4wGIvBGlDfb7fJz8cpeSqDqX3vlzUnbiAmW/mHsFxrfP1ARGdtblJMVFjVQNfmC06/Yctj0FFnNXf01HNCc1HH1g==", "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777367080; c=relaxed/simple;\n\tbh=+bCGhT/K6ChurygkZg9dxv0FarllXRmKWAVPqfhtEbI=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version;\n b=p3Ha2YiJX2ZymXykaLWyE8KUzDDOgJlcE0pwk5UVHEqzmikWtHfs6MbxW44llzSyhM8hOllEOpEpm9jVedCKPXMB0b+0quGP5gdk2XOFiNXINWRtLkz7RGlOID6IFQhRfooCOSTyxF/p6/TZ4GE0Q8IutNuKq+YDEE7/0Z1Hh1A=" ], "ARC-Authentication-Results": [ "i=2; gandalf.ozlabs.org;\n dmarc=none (p=none dis=none) header.from=huaweicloud.com;\n spf=pass (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-ext4+bounces-16169-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org", "i=1; smtp.subspace.kernel.org;\n dmarc=none (p=none dis=none) header.from=huaweicloud.com;\n spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51" ], "From": "Zhang Yi <yi.zhang@huaweicloud.com>", "To": "fstests@vger.kernel.org,\n\tzlang@kernel.org", "Cc": "linux-ext4@vger.kernel.org,\n\tlinux-fsdevel@vger.kernel.org,\n\tbfoster@redhat.com,\n\tjack@suse.cz,\n\tyi.zhang@huawei.com,\n\tyi.zhang@huaweicloud.com,\n\tyizhang089@gmail.com,\n\tyangerkun@huawei.com", "Subject": "[PATCH v3] generic/790: test post-EOF gap zeroing persistence", "Date": "Tue, 28 Apr 2026 16:57:50 +0800", "Message-ID": "<20260428085750.1072612-1-yi.zhang@huaweicloud.com>", "X-Mailer": "git-send-email 2.52.0", "Precedence": "bulk", "X-Mailing-List": "linux-ext4@vger.kernel.org", "List-Id": "<linux-ext4.vger.kernel.org>", "List-Subscribe": "<mailto:linux-ext4+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-ext4+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-CM-TRANSID": "gCh0CgBHD1sQePBp2ZtgAQ--.9895S4", "X-Coremail-Antispam": "1UD129KBjvJXoW3Xw17Cr48CryDCryUtFWDJwb_yoW3tF1kpF\n\tZ5WF1Ykr1IgF47G3s2kF1qq34ruws5Ar4Uu392grZ09ryUGr1xXa9Fqry2qay7Jrn3uw40\n\tva1kKa4Igw17ZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2\n\t9KBjDU0xBIdaVrnRJUUU9j14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0\n\trVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02\n\t1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26rxl\n\t6s0DM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s\n\t0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII\n\tjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr\n\t1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxa\n\tn2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4\n\tAY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE\n\t17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMI\n\tIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4l\n\tIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvf\n\tC2KfnxnUUI43ZEXa7VUbGQ6JUUUUU==", "X-CM-SenderInfo": "d1lo6xhdqjqx5xdzvxpfor3voofrz/", "X-Spam-Status": "No, score=-1.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDMARC_MISSING,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,\n\tSPF_HELO_NONE,SPF_PASS autolearn=disabled version=4.0.1", "X-Spam-Checker-Version": "SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org" }, "content": "From: Zhang Yi <yi.zhang@huawei.com>\n\nTest that extending a file past a non-block-aligned EOF correctly\nzero-fills the gap [old_EOF, block_boundary), and that this zeroing\npersists through a filesystem shutdown+remount cycle.\n\nStale data beyond EOF can persist on disk when append write data blocks\nare flushed before the on-disk file size update, or when concurrent\nappend writeback and mmap writes persist non-zero data past EOF.\nSubsequent post-EOF operations (append write, fallocate, truncate up)\nmust zero-fill and persist the gap to prevent exposing stale data.\n\nThe test pollutes the file's last physical block (via FIEMAP + raw\ndevice write) with a sentinel pattern beyond i_size, then performs each\nextend operation and verifies the gap is zeroed both in memory and on\ndisk.\n\nSigned-off-by: Zhang Yi <yi.zhang@huawei.com>\n---\nv2->v3:\n - Add error check for the raw device pwrite, a failed pwrite would\n silently leave the test continuing with an unpolluted block,\n producing false-positive passes.\n - Add sync_range -a to wait until the extending I/O completes and to\n ensure file size update is persisted before shutdown, preventing\n unexpected file size errors.\nv1->v2:\n - Add _require_no_realtime to prevent testing on XFS realtime devices,\n where file data may reside on $SCRATCH_RTDEV.\n - Add _exclude_fs btrfs since FIEMAP returns logical addresses, not\n physical device offsets, writing to these offsets on $SCRATCH_DEV\n would corrupt the filesystem in multi-device setups. Besides, since\n btrfs doesn't support shutdown right now, we can support it later.\n - Add -v flag to od in _check_gap_zero() to prevent line folding of\n identical consecutive lines.\n - Add expected_new_sz parameter to _test_eof_zeroing(), verify file\n size was not rolled back after shutdown+remount cycle, and also drop\n the unnecessary file size check before the shutdown as well.\n - Clarify the comment regarding when stale data beyond EOF can persist.\n\n tests/generic/790 | 168 ++++++++++++++++++++++++++++++++++++++++++\n tests/generic/790.out | 4 +\n 2 files changed, 172 insertions(+)\n create mode 100755 tests/generic/790\n create mode 100644 tests/generic/790.out", "diff": "diff --git a/tests/generic/790 b/tests/generic/790\nnew file mode 100755\nindex 00000000..6daf3793\n--- /dev/null\n+++ b/tests/generic/790\n@@ -0,0 +1,168 @@\n+#! /bin/bash\n+# SPDX-License-Identifier: GPL-2.0\n+# Copyright (c) 2026 Huawei. All Rights Reserved.\n+#\n+# FS QA Test No. 790\n+#\n+# Test that extending a file past a non-block-aligned EOF correctly zero-fills\n+# the gap [old_EOF, block_boundary), and that this zeroing persists through a\n+# filesystem shutdown+remount cycle.\n+#\n+# Stale data beyond EOF can persist on disk when:\n+# 1) append write data blocks are flushed before the on-disk file size update,\n+# and the system crashes in this window.\n+# 2) concurrent append writeback and mmap writes persist non-zero data past EOF.\n+#\n+# Subsequent post-EOF operations (append write, fallocate, truncate up) must\n+# zero-fill and persist the gap to prevent exposing stale data.\n+#\n+# The test pollutes the file's last physical block (via FIEMAP + raw device\n+# write) with a sentinel pattern beyond i_size, then performs each extend\n+# operation and verifies the gap is zeroed both in memory and on disk.\n+#\n+. ./common/preamble\n+_begin_fstest auto quick rw shutdown\n+\n+. ./common/filter\n+\n+_require_scratch\n+_require_block_device $SCRATCH_DEV\n+_require_no_realtime\n+_require_scratch_shutdown\n+_require_metadata_journaling $SCRATCH_DEV\n+\n+# FIEMAP on Btrfs returns logical addresses within the filesystem's address\n+# space, not physical device offsets. Writing to these offsets on $SCRATCH_DEV\n+# would corrupt the filesystem in multi-device setups.\n+_exclude_fs btrfs\n+\n+_require_xfs_io_command \"fiemap\"\n+_require_xfs_io_command \"falloc\"\n+_require_xfs_io_command \"pwrite\"\n+_require_xfs_io_command \"truncate\"\n+_require_xfs_io_command \"sync_range\"\n+\n+# Check that gap region [offset, offset+nbytes) is entirely zero\n+_check_gap_zero()\n+{\n+\tlocal file=\"$1\"\n+\tlocal offset=\"$2\"\n+\tlocal nbytes=\"$3\"\n+\tlocal label=\"$4\"\n+\tlocal data\n+\tlocal stripped\n+\n+\tdata=$(od -A n -t x1 -v -j $offset -N $nbytes \"$file\" 2>/dev/null)\n+\n+\t# Remove whitespace and check if any byte is non-zero\n+\tstripped=$(printf '%s' \"$data\" | tr -d ' \\n\\t')\n+\tif [ -n \"$stripped\" ] && ! echo \"$stripped\" | grep -qE \"^0+$\"; then\n+\t\techo \"FAIL: non-zero data in gap [$offset,$((offset + nbytes))) $label\"\n+\t\t_hexdump -N $((offset + nbytes)) \"$file\"\n+\t\treturn 1\n+\tfi\n+\treturn 0\n+}\n+\n+# Get the physical block offset (in bytes) of the file's first block on device\n+_get_phys_offset()\n+{\n+\tlocal file=\"$1\"\n+\tlocal fiemap_output\n+\tlocal phys_blk\n+\n+\tfiemap_output=$($XFS_IO_PROG -r -c \"fiemap -v\" \"$file\" 2>/dev/null)\n+\tphys_blk=$(echo \"$fiemap_output\" | _filter_xfs_io_fiemap | head -1 | awk '{print $3}')\n+\tif [ -z \"$phys_blk\" ]; then\n+\t\techo \"\"\n+\t\treturn\n+\tfi\n+\t# Convert 512-byte blocks to bytes\n+\techo $((phys_blk * 512))\n+}\n+\n+_test_eof_zeroing()\n+{\n+\tlocal test_name=\"$1\"\n+\tlocal extend_cmd=\"$2\"\n+\tlocal expected_new_sz=\"$3\"\n+\tlocal file=$SCRATCH_MNT/testfile_${test_name}\n+\n+\techo \"$test_name\" | tee -a $seqres.full\n+\n+\t# Compute non-block-aligned EOF offset\n+\tlocal gap_bytes=16\n+\tlocal eof_offset=$((blksz - gap_bytes))\n+\n+\t# Step 1: Write one full block to ensure the filesystem allocates a\n+\t# physical block for the file instead of using inline data.\n+\t$XFS_IO_PROG -f -c \"pwrite -S 0x5a 0 $blksz\" -c fsync \\\n+\t\t\"$file\" >> $seqres.full 2>&1\n+\n+\t# Step 2: Get physical block offset on device via FIEMAP\n+\tlocal phys_offset\n+\tphys_offset=$(_get_phys_offset \"$file\")\n+\tif [ -z \"$phys_offset\" ]; then\n+\t\t_fail \"$test_name: failed to get physical block offset via fiemap\"\n+\tfi\n+\n+\t# Step 3: Truncate file to non-block-aligned size and fsync.\n+\t# The on-disk region [eof_offset, blksz) may or may not be\n+\t# zeroed by the filesystem at this point.\n+\t$XFS_IO_PROG -c \"truncate $eof_offset\" -c fsync \\\n+\t\t\"$file\" >> $seqres.full 2>&1\n+\n+\t# Step 4: Unmount and restore the physical block to all-0x5a on disk.\n+\t# This bypasses the kernel's pagecache EOF-zeroing to ensure\n+\t# the stale pattern is present on disk. Then remount.\n+\t_scratch_unmount\n+\t$XFS_IO_PROG -d -c \"pwrite -S 0x5a $phys_offset $blksz\" \\\n+\t\t$SCRATCH_DEV >> $seqres.full 2>&1\n+\tif [ $? -ne 0 ]; then\n+\t\t_fail \"$test_name: failed to inject stale data on disk\"\n+\tfi\n+\t_scratch_mount >> $seqres.full 2>&1\n+\n+\t# Step 5: Execute the extend operation.\n+\t$XFS_IO_PROG -c \"$extend_cmd\" \"$file\" >> $seqres.full 2>&1\n+\n+\t# Step 6: Verify gap [eof_offset, blksz) is zeroed BEFORE shutdown\n+\t_check_gap_zero \"$file\" $eof_offset $gap_bytes \"before shutdown\" || return 1\n+\n+\t# Step 7: Sync the extended range and shutdown the filesystem with\n+\t# journal flush. This persists the file size extending, and\n+\t# the filesystem should persist the zeroed data in the gap\n+\t# range as well.\n+\tif [ \"$extend_cmd\" != \"${extend_cmd#pwrite}\" ]; then\n+\t\t$XFS_IO_PROG -c \"sync_range -w $blksz $blksz\" \\\n+\t\t\t-c \"sync_range -a $blksz $blksz\" \\\n+\t\t\t\"$file\" >> $seqres.full 2>&1\n+\tfi\n+\t_scratch_shutdown -f\n+\n+\t# Step 8: Remount and verify gap is still zeroed\n+\t_scratch_cycle_mount\n+\n+\t# Verify file size was not rolled back after shutdown+remount\n+\tlocal sz\n+\tsz=$(stat -c %s \"$file\")\n+\tif [ \"$sz\" -ne \"$expected_new_sz\" ]; then\n+\t\t_fail \"$test_name: file size rolled back after shutdown+remount: $sz != $expected_new_sz\"\n+\tfi\n+\n+\t_check_gap_zero \"$file\" $eof_offset $gap_bytes \"after shutdown+remount\" || return 1\n+}\n+\n+_scratch_mkfs >> $seqres.full 2>&1\n+_scratch_mount\n+\n+blksz=$(_get_block_size $SCRATCH_MNT)\n+\n+# Test three variants of EOF-extending operations\n+_test_eof_zeroing \"append_write\" \"pwrite -S 0x42 $blksz $blksz\" $((blksz * 2))\n+_test_eof_zeroing \"truncate_up\" \"truncate $((blksz * 2))\" $((blksz * 2))\n+_test_eof_zeroing \"fallocate\" \"falloc $blksz $blksz\" $((blksz * 2))\n+\n+# success, all done\n+status=0\n+exit\ndiff --git a/tests/generic/790.out b/tests/generic/790.out\nnew file mode 100644\nindex 00000000..e5e2cc09\n--- /dev/null\n+++ b/tests/generic/790.out\n@@ -0,0 +1,4 @@\n+QA output created by 790\n+append_write\n+truncate_up\n+fallocate\n", "prefixes": [ "v3" ] }