Linux Test Project
 help / color / mirror / Atom feed
From: Gaurav Pathak <gpathak@suse.de>
To: ltp@lists.linux.it
Cc: Gaurav Pathak <gaurav.pathak@suse.com>, linuxtestproject.agent@gmail.com
Subject: [LTP] [PATCH v8 0/1] statx: Add regression test for STATX_WRITE_ATOMIC on regular files
Date: Mon, 19 Oct 2026 15:46:19 +0530	[thread overview]
Message-ID: <20261019101620.370689-1-gpathak@suse.de> (raw)
In-Reply-To: <20261016105203.9420-1-linuxtestproject.agent@gmail.com>

From: Gaurav Pathak <gaurav.pathak@suse.com>

    This series adds syscalls/statx13, an LTP test exercising statx(2)'s
    STATX_WRITE_ATOMIC reporting on regular files for XFS and ext4.
    It covers the hardware-backed atomic write path (shared by both
    filesystems, where the underlying block device itself advertises
    atomic write support) as well as XFS's newer software/CoW-based
    atomic write path (Linux v6.16+), which works even on devices without
    hardware atomic write support, such as loop devices.
    
    ---
    Changes in v8:
    - Query the test device's own atomic write capability via statx()
      before formatting, instead of assuming fixed mkfs options always apply.
    - Derive the XFS/ext4 mkfs block size (and ext4 bigalloc cluster size)
      from the device's reported atomic write limits at runtime, capped at
      the 64KiB xfsprogs/e2fsprogs ceiling and at the page size unless THP
      (xfs) or blocksize_gt_pagesize (ext4) allows larger blocks.
    - Add support for XFS's software (CoW/reflink-based) atomic write path
      (Linux v6.16+), so the test produces meaningful results on loop
      devices too, not just on real or scsi_debug-emulated hardware.
    - Keep ext4 on the hardware-only path, since it has no software
      fallback; TCONF cleanly when the device lacks atomic write support.
    - Switch from .mount_device with static per-filesystem mkfs_opts to
      .needs_device + .needs_root with explicit setup()/cleanup(), to
      support the new dynamic mkfs/mount logic and TCONF branching.
    - Drop the hardcoded xfs-only .min_kver = "6.12" override; gate
      behavior on runtime statx() results instead of a fixed kernel
      version.
    - Expand the file's top comment to document the hardware vs.
      software atomic write mechanisms and the block-size constraints
      involved.
    - Link to v7: https://lore.kernel.org/r/20261016-statx-atomic-write-v7-1-d9cd4e1f1bcd@suse.com

Gaurav Pathak (1):
  statx: Add regression test for STATX_WRITE_ATOMIC on regular files


-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-10-19 10:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  7:13 [LTP] [PATCH v7] syscalls/statx13: Add basic test for STATX_WRITE_ATOMIC on regular file Gaurav Pathak
2026-10-16 10:52 ` [LTP] " linuxtestproject.agent
2026-10-19 10:16   ` Gaurav Pathak [this message]
2026-10-19 10:16     ` [LTP] [PATCH v8 1/1] statx: Add regression test for STATX_WRITE_ATOMIC on regular files Gaurav Pathak
2026-10-19 10:28   ` [LTP] [PATCH v8 2/2] " Gaurav Pathak
2026-10-19 10:28     ` [LTP] [PATCH v8 1/2] syscalls/statx13: Add test for STATX_WRITE_ATOMIC on regular file Gaurav Pathak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261019101620.370689-1-gpathak@suse.de \
    --to=gpathak@suse.de \
    --cc=gaurav.pathak@suse.com \
    --cc=linuxtestproject.agent@gmail.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox