linux-ext4 - Re: fallocate(FALLOC_FL_ZERO_RANGE_BUT_REALLY) to avoid unwritten extents?

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: <20210104202924.ugwjnbo376t3jad2@alap3.anarazel.de>
Date:   Mon, 4 Jan 2021 12:29:24 -0800
From:   Andres Freund <andres@...razel.de>
To:     Theodore Ts'o <tytso@....edu>, Matthew Wilcox <willy@...radead.org>
Cc:     linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
        linux-ext4@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: fallocate(FALLOC_FL_ZERO_RANGE_BUT_REALLY) to avoid unwritten
 extents?

Hi,

On 2021-01-04 14:17:05 -0500, Theodore Ts'o wrote:
> One thing to note is that there are some devices which support a write
> zeros operation, but where it is *less* performant than actually
> writing zeros via DMA'ing zero pages.  Yes, that's insane.
> Unfortunately, there are a insane devices out there....

That doesn't surprise me at all, unfortunately. I'm planning to send a
proposal to allow disabling a device's use of fua for similar reasons...

> That doesn't meant that your proposal shouldn't be adopted.  But it
> would be a good idea to have some kind of way to either allow some
> kind of tuning knob to disable the user of zeroout (either in the
> block device, file system, or in userspace), and/or some kind of way
> to try to automatically figure out whether using zeroout is actually a
> win, since most users aren't going to be up to adjusting a manual
> tuning knob.

A block device know seems to make sense to me. There already is
  /sys/block/*/queue/write_zeroes_max_bytes
it seems like it could make sense to add a sibling entry to allow tuning
that? Presumably with a quirks (as suggested by Matthew) to choose a
sensible default?

It's not quite analogous, but there's for
max_hw_sectors_kb/max_sectors_kb and discard_max_bytes /
discard_max_hw_bytes, and it seems like something vaguely in that
direction could make sense?

Greetings,

Andres Freund