From: Christoph Hellwig <hch@lst.de>
To: John Garry <john.g.garry@oracle.com>
Cc: alx@kernel.org, brauner@kernel.org, djwong@kernel.org,
dchinner@redhat.com, hch@lst.de, linux-man@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-kernel@vger.kernel.org, ojaswin@linux.ibm.com,
ritesh.list@gmail.com, martin.petersen@oracle.com
Subject: Re: [PATCH RFC] statx.2: Add stx_atomic_write_unit_max_opt
Date: Thu, 20 Mar 2025 08:00:48 +0100 [thread overview]
Message-ID: <20250320070048.GA14099@lst.de> (raw)
In-Reply-To: <20250319114402.3757248-1-john.g.garry@oracle.com>
On Wed, Mar 19, 2025 at 11:44:02AM +0000, John Garry wrote:
> XFS supports atomic writes - or untorn writes - based on different methods:
> - HW offload in the disk
> - Software emulation
>
> The value reported in stx_atomic_write_unit_max will be the max of the
> software emulation method.
I don't think emulation is a good word. A file system implementing
file systems things is not emulation.
> We want STATX_WRITE_ATOMIC to get this new member in addition to the
> already-existing members, so mention that a value of 0 means that
> stx_atomic_write_unit_max holds this limit.
Does that actually work? Can userspace assume all unknown statx
fields are padded to zero? If so my dio read align change could have
done away with the extra flag.
next prev parent reply other threads:[~2025-03-20 7:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 11:44 [PATCH RFC] statx.2: Add stx_atomic_write_unit_max_opt John Garry
2025-03-20 7:00 ` Christoph Hellwig [this message]
2025-03-20 9:19 ` John Garry
2025-03-20 14:12 ` Christoph Hellwig
2025-03-21 10:20 ` John Garry
2025-03-23 6:40 ` Christoph Hellwig
2025-04-03 15:07 ` John Garry
2025-04-04 9:06 ` Christoph Hellwig
2025-04-04 9:23 ` John Garry
2025-04-07 6:51 ` Christoph Hellwig
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=20250320070048.GA14099@lst.de \
--to=hch@lst.de \
--cc=alx@kernel.org \
--cc=brauner@kernel.org \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).