lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ