From: Christoph Hellwig <hch@lst.de>
To: John Garry <john.g.garry@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
chandan.babu@oracle.com, djwong@kernel.org, dchinner@redhat.com,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, catherine.hoang@oracle.com,
martin.petersen@oracle.com
Subject: Re: [PATCH v2 10/13] xfs: Unmap blocks according to forcealign
Date: Wed, 17 Jul 2024 18:42:03 +0200 [thread overview]
Message-ID: <20240717164203.GA21307@lst.de> (raw)
In-Reply-To: <9c34cf12-711e-4f36-8f65-873eaabf7283@oracle.com>
On Wed, Jul 17, 2024 at 04:24:28PM +0100, John Garry wrote:
>>>> new logic to it this might indeed be a good time.
>>> ok, I'll see if can come up with something
>> I can take a look too.
>
> I was wondering what you plans are for any clean-up/refactoring here, as
> mentioned?
Try to split all the convert left over of large rtextent / allocation
size logic out of __xfs_bunmapi and into a separate helper or two.
I started on it after writing that previous mail, but it has been
preempted by more urgent work for now.
> I was starting to look at the whole "if (forcealign) else if (big rt)" flow
> refactoring in this series to use xfs_inode_alloc_unitsize(); however, I
> figure that you have plans wider in scope, which affects this.
It will create a bit of conflict, but nothing out of ordinary.
next prev parent reply other threads:[~2024-07-17 16:42 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-05 16:24 [PATCH v2 00/13] forcealign for xfs John Garry
2024-07-05 16:24 ` [PATCH v2 01/13] xfs: only allow minlen allocations when near ENOSPC John Garry
2024-07-05 16:24 ` [PATCH v2 02/13] xfs: always tail align maxlen allocations John Garry
2024-07-05 16:24 ` [PATCH v2 03/13] xfs: simplify extent allocation alignment John Garry
2024-07-05 16:24 ` [PATCH v2 04/13] xfs: make EOF allocation simpler John Garry
2024-08-06 18:58 ` Darrick J. Wong
2024-07-05 16:24 ` [PATCH v2 05/13] xfs: introduce forced allocation alignment John Garry
2024-07-05 16:24 ` [PATCH v2 06/13] xfs: align args->minlen for " John Garry
2024-07-05 16:24 ` [PATCH v2 07/13] xfs: Introduce FORCEALIGN inode flag John Garry
2024-07-11 2:59 ` Darrick J. Wong
2024-07-11 3:59 ` Christoph Hellwig
2024-07-11 7:17 ` John Garry
2024-07-11 23:33 ` Dave Chinner
2024-07-11 23:20 ` Dave Chinner
2024-07-12 4:56 ` Christoph Hellwig
2024-07-18 8:53 ` John Garry
2024-07-23 10:11 ` John Garry
2024-07-23 14:42 ` Christoph Hellwig
2024-07-23 15:01 ` John Garry
2024-07-23 22:26 ` Darrick J. Wong
2024-07-26 14:14 ` John Garry
2024-07-23 23:38 ` Dave Chinner
2024-07-24 0:04 ` Darrick J. Wong
2024-07-24 18:50 ` John Garry
2024-07-24 7:39 ` John Garry
2024-07-05 16:24 ` [PATCH v2 08/13] xfs: Do not free EOF blocks for forcealign John Garry
2024-07-06 7:56 ` Christoph Hellwig
2024-07-08 1:44 ` Dave Chinner
2024-07-08 7:36 ` John Garry
2024-07-08 11:12 ` Dave Chinner
2024-07-08 14:41 ` John Garry
2024-07-09 7:41 ` Christoph Hellwig
2024-07-05 16:24 ` [PATCH v2 09/13] xfs: Update xfs_inode_alloc_unitsize() " John Garry
2024-07-05 16:24 ` [PATCH v2 10/13] xfs: Unmap blocks according to forcealign John Garry
2024-07-06 7:58 ` Christoph Hellwig
2024-07-08 14:48 ` John Garry
2024-07-09 7:46 ` Christoph Hellwig
2024-07-17 15:24 ` John Garry
2024-07-17 16:42 ` Christoph Hellwig [this message]
2024-07-09 9:57 ` Dave Chinner
2024-07-09 11:19 ` Christoph Hellwig
2024-07-05 16:24 ` [PATCH v2 11/13] xfs: Only free full extents for forcealign John Garry
2024-07-06 7:59 ` Christoph Hellwig
2024-07-05 16:24 ` [PATCH v2 12/13] xfs: Don't revert allocated offset " John Garry
2024-07-05 16:24 ` [PATCH v2 13/13] xfs: Enable file data forcealign feature John Garry
2024-07-06 7:53 ` [PATCH v2 00/13] forcealign for xfs Christoph Hellwig
2024-07-08 7:48 ` John Garry
2024-07-09 7:48 ` Christoph Hellwig
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=20240717164203.GA21307@lst.de \
--to=hch@lst.de \
--cc=brauner@kernel.org \
--cc=catherine.hoang@oracle.com \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.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=martin.petersen@oracle.com \
--cc=viro@zeniv.linux.org.uk \
/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.