[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a099f4fd-bde8-4a0c-b1d8-d302895374ff@oracle.com>
Date: Tue, 24 Sep 2024 10:48:02 +0100
From: John Garry <john.g.garry@...cle.com>
To: Christoph Hellwig <hch@....de>
Cc: Dave Chinner <david@...morbit.com>,
Ritesh Harjani
<ritesh.list@...il.com>, chandan.babu@...cle.com,
djwong@...nel.org, dchinner@...hat.com, viro@...iv.linux.org.uk,
brauner@...nel.org, jack@...e.cz, linux-xfs@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
catherine.hoang@...cle.com, martin.petersen@...cle.com
Subject: Re: [PATCH v4 00/14] forcealign for xfs
On 24/09/2024 07:17, Christoph Hellwig wrote:
> 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?
Yes, there are more changes than just refactoring "big alloc unit"
stuff. There are btree allocator changes.
About those btree allocator changes, strictly speaking there are just a
couple of changes to provide forcealign support - the rest are prep
patches. And those forcealign changes build on pre-existing allocator
features, like extent alignment and length specifiers.
>
>>
>>> 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).
>
It could be used, but then we have 16KB filesystem block size, which
some just may not want. And we just don't want 16KB sector size, but I
don't think that we require that if we use RWF_ATOMIC.
Powered by blists - more mailing lists