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 1/1] statx: Add regression test for STATX_WRITE_ATOMIC on regular files
Date: Mon, 19 Oct 2026 15:46:20 +0530	[thread overview]
Message-ID: <20261019101620.370689-2-gpathak@suse.de> (raw)
In-Reply-To: <20261019101620.370689-1-gpathak@suse.de>

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

Signed-off-by: Gaurav Pathak <gaurav.pathak@suse.com>

--- b4-submit-tracking ---
# This section is used internally by b4 prep for tracking purposes.
{
  "series": {
    "revision": 1,
    "change-id": "20261019-statx-atomic-write-1919fc099e97",
    "prefixes": []
  }
}
-- 
2.51.0


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

  reply	other threads:[~2026-10-19 10:17 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   ` [LTP] [PATCH v8 0/1] statx: Add regression test for STATX_WRITE_ATOMIC on regular files Gaurav Pathak
2026-10-19 10:16     ` Gaurav Pathak [this message]
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-2-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