From: John Garry <john.g.garry@oracle.com>
To: Vitaliy Filippov <vitalifster@gmail.com>
Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: remove power of 2 and length boundary atomic write restrictions
Date: Wed, 7 Jan 2026 10:51:13 +0000 [thread overview]
Message-ID: <704e5d2a-1b37-43c5-8ad6-bda47a4e7fc6@oracle.com> (raw)
In-Reply-To: <CAPqjcqq+DFc4TwAPDZodZ61b5pRrt4i+moy3K1dkzGhH9r-2Rw@mail.gmail.com>
On 06/01/2026 13:08, Vitaliy Filippov wrote:
>> For ext4, the maximum atomic write size is limited to the bigalloc
>> cluster size. Disk blocks are allocated to this cluster size granularity
>> and alignment. As such, a properly aligned atomic write <= cluster size
>> can never span discontiguous disk blocks.
>
> Ok, thank you for the explanation.
>
> But it seems that it's an internal implementation detail of ext4,
> right?
I think that it is fair to say that alignment constraints of atomic
write HW should mean specific alignment and granularity of FS disk blocks.
> So this check should be done inside ext4 code. And in fact I
> suspect it's actually already done there because generic checks which
> I suggest to remove can't take ext4 cluster size into account, so at
> least some atomic write validation is already done inside ext4. The
> only thing that's left is to move the write alignment check there too.
>
> Another thing that suggests that it's an internal implementation
> detail is that a CoW filesystem like ZFS or btrfs can probably provide
> atomic write guarantees for unaligned writes too, and probably even
> without hardware atomic write support.
Yes, xfs already does this.
>
> Can my change be limited to raw block devices then?
The atomic write API is based on:
a. doing statx to find atomic write min and max limits.
b. issuing a write with RWF_ATOMIC means that the write should be
naturally aligned and fit within the size limits.
That is the same for both raw block devices and regular FS files. And
any atomic write boundary is not part of the API.
>Thanks to your
> explanation now I understand the motivation for these checks with
> ext4, but they still make no sense for the raw NVMe disk.
>
> I mean, can you approve my change if I rework it to only lift 2^N and
> alignment checks for raw block devices and not for file systems? For
> example if I move these checks directly to the related ext4 and xfs
> code? I think it's the right place to do them.
What is the actual usecase you are trying to solve? You mentioned "avoid
journaling", which does not explain what you want to achieve.
You could arrange your data so that it suits the rules.
next prev parent reply other threads:[~2026-01-07 10:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-24 11:53 [PATCH] fs: remove power of 2 and length boundary atomic write restrictions Vitaliy Filippov
2025-12-29 7:15 ` kernel test robot
2025-12-30 7:54 ` John Garry
2025-12-30 9:01 ` Vitaliy Filippov
2026-01-02 17:41 ` John Garry
2026-01-05 18:58 ` Vitaliy Filippov
2026-01-06 9:06 ` John Garry
2026-01-06 10:50 ` Vitaliy Filippov
2026-01-06 11:26 ` John Garry
2026-01-06 13:08 ` Vitaliy Filippov
2026-01-07 10:51 ` John Garry [this message]
2026-01-07 13:05 ` Vitaliy Filippov
2026-01-07 15:42 ` John Garry
2026-01-07 16:21 ` Vitaliy Filippov
2026-01-08 18:18 ` Vitaliy Filippov
2026-01-13 14:25 ` Vitaliy Filippov
2026-01-05 19:29 ` Vitaliy Filippov
2026-01-05 19:44 ` Vitaliy Filippov
2026-01-06 10:55 ` Vitaliy Filippov
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=704e5d2a-1b37-43c5-8ad6-bda47a4e7fc6@oracle.com \
--to=john.g.garry@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=vitalifster@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