From: John Garry <john.g.garry@oracle.com>
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Cc: Jan Kara <jack@suse.cz>, Theodore Ts'o <tytso@mit.edu>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Matthew Wilcox <willy@infradead.org>,
"Darrick J . Wong" <djwong@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
linux-kernel@vger.kernel.org, Dave Chinner <david@fromorbit.com>
Subject: Re: [RFC] ext4: Add support for ext4_map_blocks_atomic()
Date: Mon, 18 Mar 2024 08:22:15 +0000 [thread overview]
Message-ID: <22a24d3c-9d0e-410b-a49c-b89d0c00ccd8@oracle.com> (raw)
In-Reply-To: <87r0gcn74h.fsf@doe.com>
On 14/03/2024 15:52, Ritesh Harjani (IBM) wrote:
>> and same as method 3 at
>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/cover.1709356594.git.ritesh.list@gmail.com/?__;!!ACWV5N9M2RV99hQ!Pb-HbBdm2OWUIGDFfG1OkemtRSy2LyHsc5s6WiyTtGHW4uGWV6sMkoVjmknmBydf_i6TF_CDqp7dR0Y-CGY8EIc$
> Hi John,
>
> No. So this particular patch to add ext4_map_blocks_atomic() method is
> only to support the usecase which you listed should work for a good user
> behaviour. This is because, with bigalloc we advertizes fsawu_min and
> fsawu_max as [blocksize, clustersize]
> i.e.
>
> That means a user should be allowed to -
> 1. pwrite 0 4k /mnt/test/f1
> followed by
> 2. pwrite 0 16k /mnt/test/f1
>
>
> So earlier we were failing the second 16k write at an offset where there
> is already an existing extent smaller that 16k (that was because of the
> assumption that the most of the users won't do such a thing).
>
> But for a more general usecase, it is not difficult to support the
> second 16k write in such a way for atomic writes with bigalloc,
> so this patch just adds that support to this series.
Is there some reason for which the generic iomap solution in
https://lore.kernel.org/linux-xfs/20240304130428.13026-1-john.g.garry@oracle.com/
won't work? That is, you would just need to set iomap->extent_shift
appropriately. I will note that we gate this feature on XFS based on
forcealign enabled for the inode - I am not sure if you would want this
always for bigalloc.
Thanks,
John
prev parent reply other threads:[~2024-03-18 8:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-02 7:41 [RFC 0/9] ext4: Add direct-io atomic write support using fsawu Ritesh Harjani (IBM)
2024-03-02 7:41 ` [RFC 1/8] fs: Add FS_XFLAG_ATOMICWRITES flag Ritesh Harjani (IBM)
2024-03-02 7:41 ` [RFC 2/8] fs: Reserve inode flag FS_ATOMICWRITES_FL for atomic writes Ritesh Harjani (IBM)
2024-03-04 0:59 ` Dave Chinner
2024-03-08 7:19 ` Ojaswin Mujoo
2024-03-02 7:42 ` [RFC 3/8] iomap: Add atomic write support for direct-io Ritesh Harjani (IBM)
2024-03-04 1:16 ` Dave Chinner
2024-03-04 5:33 ` Ritesh Harjani
2024-03-04 8:49 ` John Garry
2024-03-04 10:31 ` Ritesh Harjani
2024-03-04 20:56 ` Dave Chinner
2024-03-02 7:42 ` [RFC 4/8] ext4: Add statx and other atomic write helper routines Ritesh Harjani (IBM)
2024-03-06 11:14 ` John Garry
2024-03-08 8:10 ` Ritesh Harjani
2024-03-02 7:42 ` [RFC 5/8] ext4: Adds direct-io atomic writes checks Ritesh Harjani (IBM)
2024-03-02 7:42 ` [RFC 6/8] ext4: Add an inode flag for atomic writes Ritesh Harjani (IBM)
2024-03-04 20:34 ` Dave Chinner
2024-03-08 8:02 ` Ritesh Harjani
2024-03-02 7:42 ` [RFC 7/8] ext4: Enable FMODE_CAN_ATOMIC_WRITE in open for direct-io Ritesh Harjani (IBM)
2024-03-02 7:42 ` [RFC 8/8] ext4: Adds atomic writes using fsawu Ritesh Harjani (IBM)
2024-03-02 7:42 ` [RFC 9/9] e2fsprogs/chattr: Supports atomic writes attribute Ritesh Harjani (IBM)
2024-03-06 11:22 ` [RFC 0/9] ext4: Add direct-io atomic write support using fsawu John Garry
2024-03-06 13:13 ` Ritesh Harjani
2024-03-08 20:25 ` [RFC] ext4: Add support for ext4_map_blocks_atomic() Ritesh Harjani (IBM)
2024-03-09 2:37 ` Ritesh Harjani
2024-03-13 18:40 ` John Garry
2024-03-14 15:52 ` Ritesh Harjani
2024-03-18 8:22 ` John Garry [this message]
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=22a24d3c-9d0e-410b-a49c-b89d0c00ccd8@oracle.com \
--to=john.g.garry@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
/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).