From: Christian Brauner <brauner@kernel.org>
To: Chandan Babu R <chandanbabu@kernel.org>
Cc: Zhang Yi <yi.zhang@huaweicloud.com>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, djwong@kernel.org,
hch@infradead.org, david@fromorbit.com, tytso@mit.edu,
jack@suse.cz, yi.zhang@huawei.com, chengzhihao1@huawei.com,
yukuai3@huawei.com
Subject: Re: [PATCH v4 0/9] xfs/iomap: fix non-atomic clone operation and don't update size when zeroing range post eof
Date: Wed, 17 Apr 2024 13:40:36 +0200 [thread overview]
Message-ID: <20240417-finster-kichern-31077915c0be@brauner> (raw)
In-Reply-To: <87ttk0d2ck.fsf@debian-BULLSEYE-live-builder-AMD64>
On Wed, Apr 17, 2024 at 10:12:10AM +0530, Chandan Babu R wrote:
> On Wed, Mar 20, 2024 at 07:05:39 PM +0800, Zhang Yi wrote:
> > Changes since v3:
> > - Improve some git message comments and do some minor code cleanup, no
> > logic changes.
> >
> > Changes since v2:
> > - Merge the patch for dropping of xfs_convert_blocks() and the patch
> > for modifying xfs_bmapi_convert_delalloc().
> > - Reword the commit message of the second patch.
> >
> > Changes since v1:
> > - Make xfs_bmapi_convert_delalloc() to allocate the target offset and
> > drop the writeback helper xfs_convert_blocks().
> > - Don't use xfs_iomap_write_direct() to convert delalloc blocks for
> > zeroing posteof case, use xfs_bmapi_convert_delalloc() instead.
> > - Fix two off-by-one issues when converting delalloc blocks.
> > - Add a separate patch to drop the buffered write failure handle in
> > zeroing and unsharing.
> > - Add a comments do emphasize updating i_size should under folio lock.
> > - Make iomap_write_end() to return a boolean, and do some cleanups in
> > buffered write begin path.
> >
> > This patch series fix a problem of exposing zeroed data on xfs since the
> > non-atomic clone operation. This problem was found while I was
> > developing ext4 buffered IO iomap conversion (ext4 is relying on this
> > fix [1]), the root cause of this problem and the discussion about the
> > solution please see [2]. After fix the problem, iomap_zero_range()
> > doesn't need to update i_size so that ext4 can use it to zero partial
> > block, e.g. truncate eof block [3].
> >
> > [1] https://lore.kernel.org/linux-ext4/20240127015825.1608160-1-yi.zhang@huaweicloud.com/
> > [2] https://lore.kernel.org/linux-ext4/9b0040ef-3d9d-6246-4bdd-82b9a8f55fa2@huaweicloud.com/
> > [3] https://lore.kernel.org/linux-ext4/9c9f1831-a772-299b-072b-1c8116c3fb35@huaweicloud.com/
> >
> > Thanks,
> > Yi.
> >
> > Zhang Yi (9):
> > xfs: match lock mode in xfs_buffered_write_iomap_begin()
> > xfs: make the seq argument to xfs_bmapi_convert_delalloc() optional
> > xfs: make xfs_bmapi_convert_delalloc() to allocate the target offset
> > xfs: convert delayed extents to unwritten when zeroing post eof blocks
> > iomap: drop the write failure handles when unsharing and zeroing
> > iomap: don't increase i_size if it's not a write operation
> > iomap: use a new variable to handle the written bytes in
> > iomap_write_iter()
> > iomap: make iomap_write_end() return a boolean
> > iomap: do some small logical cleanup in buffered write
> >
>
> Hi all,
>
> I have picked up this patchset for inclusion into XFS' 6.10-rc1 patch
> queue. Please let me know if there are any objections.
It'd be nice if I could take the iomap patches into the vfs.iomap tree
that you can then pull from if you depend on it.. There's already some
cleanups in there. Sounds ok?
next prev parent reply other threads:[~2024-04-17 11:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 11:05 [PATCH v4 0/9] xfs/iomap: fix non-atomic clone operation and don't update size when zeroing range post eof Zhang Yi
2024-03-20 11:05 ` [PATCH v4 1/9] xfs: match lock mode in xfs_buffered_write_iomap_begin() Zhang Yi
2024-03-20 11:05 ` [PATCH v4 2/9] xfs: make the seq argument to xfs_bmapi_convert_delalloc() optional Zhang Yi
2024-03-20 11:05 ` [PATCH v4 3/9] xfs: make xfs_bmapi_convert_delalloc() to allocate the target offset Zhang Yi
2024-03-20 11:05 ` [PATCH v4 4/9] xfs: convert delayed extents to unwritten when zeroing post eof blocks Zhang Yi
2024-04-23 11:17 ` [PATCH v5 " Zhang Yi
2024-04-25 12:22 ` Christoph Hellwig
2024-04-25 12:32 ` Zhang Yi
2024-03-20 11:05 ` [PATCH v4 5/9] iomap: drop the write failure handles when unsharing and zeroing Zhang Yi
2024-03-20 11:05 ` [PATCH v4 6/9] iomap: don't increase i_size if it's not a write operation Zhang Yi
2024-04-19 6:07 ` Chandan Babu R
2024-04-19 8:14 ` Zhang Yi
2024-04-23 11:30 ` Zhang Yi
2024-03-20 11:05 ` [PATCH v4 7/9] iomap: use a new variable to handle the written bytes in iomap_write_iter() Zhang Yi
2024-03-20 11:05 ` [PATCH v4 8/9] iomap: make iomap_write_end() return a boolean Zhang Yi
2024-03-20 11:05 ` [PATCH v4 9/9] iomap: do some small logical cleanup in buffered write Zhang Yi
2024-04-17 4:42 ` [PATCH v4 0/9] xfs/iomap: fix non-atomic clone operation and don't update size when zeroing range post eof Chandan Babu R
2024-04-17 11:40 ` Christian Brauner [this message]
2024-04-18 9:30 ` Chandan Babu R
2024-04-25 12:25 ` (subset) " Christian Brauner
2024-04-29 11:48 ` Chandan Babu R
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=20240417-finster-kichern-31077915c0be@brauner \
--to=brauner@kernel.org \
--cc=chandanbabu@kernel.org \
--cc=chengzhihao1@huawei.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.com \
--cc=yukuai3@huawei.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