[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4dbdcc6c-6bd1-faf4-7187-cc048acd2125@samsung.com>
Date: Mon, 18 Sep 2023 14:35:27 +0200
From: Pankaj Raghav <p.raghav@...sung.com>
To: Matthew Wilcox <willy@...radead.org>,
Pankaj Raghav <kernel@...kajraghav.com>
CC: <linux-xfs@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
<david@...morbit.com>, <da.gomez@...sung.com>,
<akpm@...ux-foundation.org>, <linux-kernel@...r.kernel.org>,
<djwong@...nel.org>, <linux-mm@...ck.org>,
<chandan.babu@...cle.com>, <mcgrof@...nel.org>,
<gost.dev@...sung.com>
Subject: Re: [RFC 00/23] Enable block size > page size in XFS
On 2023-09-15 20:50, Matthew Wilcox wrote:
> On Fri, Sep 15, 2023 at 08:38:25PM +0200, Pankaj Raghav wrote:
>> Only XFS was enabled and tested as a part of this series as it has
>> supported block sizes up to 64k and sector sizes up to 32k for years.
>> The only thing missing was the page cache magic to enable bs > ps. However any filesystem
>> that doesn't depend on buffer-heads and support larger block sizes
>> already should be able to leverage this effort to also support LBS,
>> bs > ps.
>
> I think you should choose whether you're going to use 'bs > ps' or LBS
> and stick to it. They're both pretty inscrutable and using both
> interchanagbly is worse.
>
Got it! Probably I will stick to Large block size and explain what it means
at the start of the patchset.
> But I think filesystems which use buffer_heads should be fine to support
> bs > ps. The problems with the buffer cache are really when you try to
> support small block sizes and large folio sizes (eg arrays of bhs on
> the stack). Supporting bs == folio_size shouldn't be a problem.
>
I remember some patches from you trying to avoid the stack limitation while working
with bh. Thanks for the clarification!
Powered by blists - more mailing lists