linux-ext4 - Re: [LSF/MM TOPIC] More async operations for file systems

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: <20190220234723.GA5999@localhost.localdomain>
Date:   Wed, 20 Feb 2019 16:47:24 -0700
From:   Keith Busch <keith.busch@...el.com>
To:     Ric Wheeler <ricwheeler@...il.com>
Cc:     Dave Chinner <david@...morbit.com>,
        lsf-pc@...ts.linux-foundation.org,
        linux-xfs <linux-xfs@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4 <linux-ext4@...r.kernel.org>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        linux-block@...r.kernel.org
Subject: Re: [LSF/MM TOPIC] More async operations for file systems - async
 discard?

On Sun, Feb 17, 2019 at 06:42:59PM -0500, Ric Wheeler wrote:
> I think the variability makes life really miserable for layers above it.
> 
> Might be worth constructing some tooling that we can use to validate or
> shame vendors over - testing things like a full device discard, discard of
> fs block size and big chunks, discard against already discarded, etc.

With respect to fs block sizes, one thing making discards suck is that
many high capacity SSDs' physical page sizes are larger than the fs block
size, and a sub-page discard is worse than doing nothing.

We've discussed previously about supporting block size larger than
the system's page size, but it doesn't look like that's gone anywhere.
Maybe it's worth revisiting since it's really inefficient if you write
or discard at the smaller granularity.