[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZoOta_ot6UNvB6i5@infradead.org>
Date: Tue, 2 Jul 2024 00:34:03 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Zhang Yi <yi.zhang@...weicloud.com>, linux-xfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
djwong@...nel.org, hch@...radead.org, brauner@...nel.org,
chandanbabu@...nel.org, John Garry <john.g.garry@...cle.com>,
jack@...e.cz, yi.zhang@...wei.com, chengzhihao1@...wei.com,
yukuai3@...wei.com
Subject: Re: [PATCH -next v6 1/2] xfs: reserve blocks for truncating large
realtime inode
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.
Powered by blists - more mailing lists