[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c5e418c8-e9eb-4733-902f-a1000be1ad73@oracle.com>
Date: Fri, 15 Nov 2024 08:14:55 +0000
From: John Garry <john.g.garry@...cle.com>
To: Dave Chinner <dchinner@...hat.com>, Long Li <leo.lilong@...wei.com>
Cc: Dave Chinner <david@...morbit.com>,
Ritesh Harjani
<ritesh.list@...il.com>, chandan.babu@...cle.com,
djwong@...nel.org, hch@....de, 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 14/11/2024 20:07, Dave Chinner wrote:
>> xfs_io -c "pwrite 64k 64k" mnt/file
>> xfs_io -c "pwrite 8k 8k" mnt/file
>>
>> If unaligned unwritten extents are not permitted, we need to zero out the
>> sub-allocation units for ranges [0, 8K] and [16K, 64K] to prevent stale
>> data. While this can be handled relatively easily in direct I/O scenarios,
>> it presents significant challenges in buffered I/O operations. The main
>> difficulty arises because the extent size (64K) is larger than the page
>> size (4K), and our current code base has substantial limitations in handling
>> such cases.
>>
>> Any thoughts on this?
> Large folios in the page cache solve this problem. i.e. it's the
> same problem that block size > page size support had to solve.
Would that work for an extsize which is not a power-of-2?
Powered by blists - more mailing lists