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]
Date:   Wed, 19 Apr 2023 07:03:31 +0200
From:   "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Neal Gompa <neal@...pa.dev>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Sterba <dsterba@...e.com>, David Sterba <dsterba@...e.cz>,
        linux-kernel@...r.kernel.org, Rafael Wysocki <rafael@...nel.org>,
        Chris Mason <clm@...a.com>, Boris Burkov <boris@....io>,
        regressions@...ts.linux.dev
Subject: Re: Linux regressions report for mainline [2023-04-16]

On 18.04.23 23:32, Neal Gompa wrote:
> 
> I'm the guy that sort of kickstarted this whole thing a year ago.
>>>From my perspective in Fedora-land, we've been running automatic
> weekly fstrim on every Fedora system for three years now[1] and
> have not received any complaints about SSDs pushing daises from
> that.
> 
> When we started discussing btrfs discard=async within Fedora
> two years ago[2], I started soliciting feedback and information
> from the Btrfs developers I was regularly working with at the time.
> 
> Last year, I had a face-to-face with Chris Mason and we discussed
> the idea in depth and decided to go for this, based on both Fedora's
> data with consumer disks and Facebook's data with their datacenters.
> 
> The only real surprise we had was the so-called "discard storm",
> which Boris Burkov made adjustments to resolve a couple weeks ago[3].
> [...]
> [3]: https://lore.kernel.org/linux-btrfs/cover.1680723651.git.boris@bur.io/T/#t

Wait, what? Argh. Sorry, if I had seen that patch, I wouldn't have
brought this up in my report at all. I missed it, as I wasn't CCed; and
regzbot missed it, because the patch uses a odd format for the lore link
(but not totally uncommon, will change regzbot to ensure that doesn't
happen again).

Ciao, Thorsten

P.S.: /me meanwhile yet again wonders if we should tell people to add a
"CC: <regressions@...ts.linux.dev>" on patches fixing regressions. Then
in this case I would have become aware of the patch. And it makes it
obvious for anybody handling patches that the patch is fixing a
regression. But whatever, might not be worth it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ