From: Dave Chinner <david@fromorbit.com>
To: Zhang Yi <yi.zhang@huaweicloud.com>
Cc: Chandan Babu R <chandanbabu@kernel.org>,
djwong@kernel.org, Christoph Hellwig <hch@infradead.org>,
brauner@kernel.org,
Linux-XFS mailing list <linux-xfs@vger.kernel.org>
Subject: Re: [BUG REPORT] generic/561 fails when testing xfs on next-20240506 kernel
Date: Sat, 11 May 2024 18:19:24 +1000 [thread overview]
Message-ID: <Zj8qDHJBL5igjVrJ@destitution> (raw)
In-Reply-To: <966892ef-9b47-3891-e2d2-48889d46223d@huaweicloud.com>
On Sat, May 11, 2024 at 03:43:17PM +0800, Zhang Yi wrote:
> On 2024/5/11 11:45, Dave Chinner wrote:
> > On Sat, May 11, 2024 at 11:11:32AM +0800, Zhang Yi wrote:
> >> On 2024/5/8 17:01, Chandan Babu R wrote:
> > It might actually be easiest to pass the block size for zeroing into
> > iomap_truncate_page() rather than relying on being able to extract
> > the zeroing range from the inode via i_blocksize(). We can't use
> > i_blocksize() for RT files, because inode->i_blkbits and hence
> > i_blocksize() only supports power of 2 block sizes. Changing that is
> > a *much* bigger job, so fixing xfs_truncate_page() is likely the
> > best thing to do right now...
> >
>
> Thanks for the explanation and suggestion, I agree with you. However,
> why do you recommend to pass block size for zeroing in to
> iomap_truncate_page()? It's looks like we could fix xfs_truncate_page()
> by using iomap_zero_range() and dax_zero_range() instead and don't use
> iomap_truncate_page() and dax_truncate_page().
Fair question. Yes, we could just fix it in XFS.
But then any other filesystem that uses iomap might have the same
problem where the allocation block size (and hence the range that
needs zeroing) is different to the filesystem block size (e.g. ext4
with bigalloc?). At that point, those filesystem developers need to:
a) be aware of the issue; and
b) implement their own iomap_zero_range() wrapper for the
same function.
If the iomap infrastructure doesn't assume block sizes are always
i_blocksize() (which is clearly a bad assumption!), then the API
itself informs the filesystem developers of the fact they really
have to care about using the correct allocation block sizes during
EOF zeroing.
At the moment, only XFS uses iomap_truncate_page(), and only ext2
and XFS use dax_truncate_page(). It seems pretty simple to change
the infrastructure and document why we don't use i_blocksize() at
this point. Especially considering we have forced alignment stuff in
XFS coming up which further decouples allocation unit (and hence
zeroing range) from the filesystem block size....
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2024-05-11 8:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-08 9:01 [BUG REPORT] generic/561 fails when testing xfs on next-20240506 kernel Chandan Babu R
2024-05-11 3:11 ` Zhang Yi
2024-05-11 3:45 ` Dave Chinner
2024-05-11 7:43 ` Zhang Yi
2024-05-11 8:19 ` Dave Chinner [this message]
2024-05-11 9:27 ` Zhang Yi
2024-05-15 3:10 ` Zhang Yi
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=Zj8qDHJBL5igjVrJ@destitution \
--to=david@fromorbit.com \
--cc=brauner@kernel.org \
--cc=chandanbabu@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=yi.zhang@huaweicloud.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).