All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.