From: Christoph Hellwig <hch@lst.de>
To: John Garry <john.g.garry@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
Dave Chinner <david@fromorbit.com>,
Ritesh Harjani <ritesh.list@gmail.com>,
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 v4 00/14] forcealign for xfs
Date: Tue, 24 Sep 2024 08:17:19 +0200 [thread overview]
Message-ID: <20240924061719.GA11211@lst.de> (raw)
In-Reply-To: <c702379b-3f37-448d-ac28-ec1e248a6c65@oracle.com>
On Mon, Sep 23, 2024 at 01:33:12PM +0100, John Garry wrote:
>> As a first step by not making it worse, and that not only means not
>> spreading the rtextent stuff further,
>
> I assume that refactoring rtextent into "big alloc unit" is spreading
> (rtextent stuff), right? If so, what other solution? CoW?
Well, if you look at the force align series you'd agree that it
spreads the thing out into the btree allocator. Or do I misread it?
>
>> but more importantly not introducing
>> additional complexities by requiring to be able to write over the
>> written/unwritten boundaries created by either rtextentsize > 1 or
>> the forcealign stuff if you actually want atomic writes.
>
> The very original solution required a single mapping and in written state
> for atomic writes. Reverting to that would save a lot of hassle in the
> kernel. It just means that the user needs to manually pre-zero.
What atomic I/O sizes do your users require? Would they fit into
a large sector size now supported by XFS (i.e. 32k for now).
next prev parent reply other threads:[~2024-09-24 6:17 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 16:36 [PATCH v4 00/14] forcealign for xfs John Garry
2024-08-13 16:36 ` [PATCH v4 01/14] xfs: only allow minlen allocations when near ENOSPC John Garry
2024-08-23 16:28 ` Darrick J. Wong
2024-08-13 16:36 ` [PATCH v4 02/14] xfs: always tail align maxlen allocations John Garry
2024-08-23 16:31 ` Darrick J. Wong
2024-08-29 17:58 ` John Garry
2024-08-29 21:34 ` Darrick J. Wong
2024-08-13 16:36 ` [PATCH v4 03/14] xfs: simplify extent allocation alignment John Garry
2024-08-13 16:36 ` [PATCH v4 04/14] xfs: make EOF allocation simpler John Garry
2024-09-04 18:25 ` Ritesh Harjani
2024-09-05 7:51 ` John Garry
2024-08-13 16:36 ` [PATCH v4 05/14] xfs: introduce forced allocation alignment John Garry
2024-08-13 16:36 ` [PATCH v4 06/14] xfs: align args->minlen for " John Garry
2024-08-13 16:36 ` [PATCH v4 07/14] xfs: Introduce FORCEALIGN inode flag John Garry
2024-08-13 16:36 ` [PATCH v4 08/14] xfs: Update xfs_inode_alloc_unitsize() for forcealign John Garry
2024-08-13 16:36 ` [PATCH v4 09/14] xfs: Update xfs_setattr_size() " John Garry
2024-08-13 16:36 ` [PATCH v4 10/14] xfs: Do not free EOF blocks " John Garry
2024-08-13 16:36 ` [PATCH v4 11/14] xfs: Only free full extents " John Garry
2024-08-13 16:36 ` [PATCH v4 12/14] xfs: Unmap blocks according to forcealign John Garry
2024-08-23 16:35 ` Darrick J. Wong
2024-08-13 16:36 ` [PATCH v4 13/14] xfs: Don't revert allocated offset for forcealign John Garry
2024-08-13 16:36 ` [PATCH v4 14/14] xfs: Enable file data forcealign feature John Garry
2024-09-04 18:14 ` [PATCH v4 00/14] forcealign for xfs Ritesh Harjani
2024-09-04 23:20 ` Dave Chinner
2024-09-05 3:56 ` Ritesh Harjani
2024-09-05 6:33 ` Dave Chinner
2024-09-10 2:51 ` Ritesh Harjani
2024-09-16 6:33 ` Dave Chinner
2024-09-10 12:33 ` Ritesh Harjani
2024-09-16 7:03 ` Dave Chinner
2024-09-16 10:24 ` John Garry
2024-09-17 20:54 ` Darrick J. Wong
2024-09-17 23:34 ` Dave Chinner
2024-09-17 22:12 ` Dave Chinner
2024-09-18 7:59 ` John Garry
2024-09-23 2:57 ` Dave Chinner
2024-09-23 3:33 ` Christoph Hellwig
2024-09-23 8:16 ` John Garry
2024-09-23 12:07 ` Christoph Hellwig
2024-09-23 12:33 ` John Garry
2024-09-24 6:17 ` Christoph Hellwig [this message]
2024-09-24 9:48 ` John Garry
2024-11-29 11:36 ` John Garry
2024-09-23 8:00 ` John Garry
2024-09-05 10:15 ` John Garry
2024-09-05 21:47 ` Dave Chinner
2024-09-06 14:31 ` John Garry
2024-09-08 22:49 ` Dave Chinner
2024-09-09 16:18 ` John Garry
2024-09-16 5:25 ` Dave Chinner
2024-09-16 9:44 ` John Garry
2024-09-17 22:27 ` Dave Chinner
2024-09-18 10:12 ` John Garry
2024-11-14 12:48 ` Long Li
2024-11-14 16:22 ` John Garry
2024-11-14 20:07 ` Dave Chinner
2024-11-15 8:14 ` John Garry
2024-11-15 11:20 ` Long Li
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=20240924061719.GA11211@lst.de \
--to=hch@lst.de \
--cc=brauner@kernel.org \
--cc=catherine.hoang@oracle.com \
--cc=chandan.babu@oracle.com \
--cc=david@fromorbit.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=ritesh.list@gmail.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 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).