From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
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, brauner@kernel.org, chandanbabu@kernel.org,
John Garry <john.g.garry@oracle.com>,
jack@suse.cz, yi.zhang@huawei.com, chengzhihao1@huawei.com,
yukuai3@huawei.com
Subject: Re: [PATCH -next v6 1/2] xfs: reserve blocks for truncating large realtime inode
Date: Tue, 2 Jul 2024 00:34:03 -0700 [thread overview]
Message-ID: <ZoOta_ot6UNvB6i5@infradead.org> (raw)
In-Reply-To: <ZoKie9aZV0sHIbA8@dread.disaster.area>
On Mon, Jul 01, 2024 at 10:35:07PM +1000, Dave Chinner wrote:
> Sorry, but I don't really care what either John or Christoph say on
> this matter: xfs_inode_has_bigrtalloc() is recently introduced
> technical debt that should not be propagated further.
So send a patch to fix it.
> xfs_inode_has_bigrtalloc() needs to be replaced completely with
> xfs_inode_alloc_unitsize() and any conditional behaviour needed can
> be based on the return value from xfs_inode_alloc_unitsize(). That
> works for everything that has an allocation block size larger than
> one filesystem block, not just one specific RT case.
Only assuming we actually get these larger alloc sizes. Which right
now we don't have, and to be honest I'm not sure they are a good
idea. The whole larger alloc size thing has been a massive pain
to deal with, and we'll need good argument for furthering that pain.
next prev parent reply other threads:[~2024-07-02 7:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 14:21 [PATCH -next v6 0/2] iomap/xfs: fix stale data exposure when truncating realtime inodes Zhang Yi
2024-06-18 14:21 ` [PATCH -next v6 1/2] xfs: reserve blocks for truncating large realtime inode Zhang Yi
2024-07-01 1:16 ` Dave Chinner
2024-07-01 2:26 ` Zhang Yi
2024-07-01 12:35 ` Dave Chinner
2024-07-02 7:34 ` Christoph Hellwig [this message]
2024-06-18 14:21 ` [PATCH -next v6 2/2] iomap: don't increase i_size in iomap_write_end() Zhang Yi
2024-06-19 5:57 ` Christoph Hellwig
2024-06-19 0:24 ` [PATCH -next v6 0/2] iomap/xfs: fix stale data exposure when truncating realtime inodes Darrick J. Wong
2024-06-19 1:52 ` Zhang Yi
2024-06-19 14:01 ` Christian Brauner
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=ZoOta_ot6UNvB6i5@infradead.org \
--to=hch@infradead.org \
--cc=brauner@kernel.org \
--cc=chandanbabu@kernel.org \
--cc=chengzhihao1@huawei.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).