regressions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <clm@meta.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Linux regressions mailing list <regressions@lists.linux.dev>,
	Sergei Trofimovich <slyich@gmail.com>,
	Josef Bacik <josef@toxicpanda.com>,
	Christopher Price <pricechrispy@gmail.com>,
	anand.jain@oracle.com, boris@bur.io, clm@fb.com,
	dsterba@suse.com, linux-btrfs@vger.kernel.org
Subject: Re: [6.2 regression][bisected]discard storm on idle since v6.1-rc8-59-g63a7cb130718 discard=async
Date: Wed, 5 Apr 2023 08:01:53 -0400	[thread overview]
Message-ID: <da8e4122-9e6a-fe4a-d064-30577a03ec00@meta.com> (raw)
In-Reply-To: <ZC0SyJbFJuS2ZEOY@infradead.org>

On 4/5/23 2:18 AM, Christoph Hellwig wrote:
> On Tue, Apr 04, 2023 at 02:15:38PM -0400, Chris Mason wrote:
>> It seems like a good time to talk through a variations of discard usage
>> in fb data centers.  We run a pretty wide variety of hardware from
>> consumer grade ssds to enterprise ssds, and we've run these on
>> ext4/btrfs/xfs.
> 
> Remember what you guys call consumer grade is the top of the shelve
> consumer grade SSDs, or in fact low-end enterprise ones that are based
> on the latest and greatest top shelve SSDs with firmware specifically
> tweaked for you.  That is a whole differnet level from random crappy
> no-name SSD from 5 years ago.
> 

This is definitely true, our providers are reliable and support the
products well.  But, you also have to factor in the write cycles, drive
lifetimes, and just the constant threat of statistics at scale.  Drives
might come in off something close to the top shelf, but datacenters are
pretty hard on storage.

Going back to the fedora thread, we've definitely had ssds with
reliability issues caused by trims, but we haven't had any I can think
of where mount -o discard was fundamentally less reliable than periodic
full device trimming.

-chris


  reply	other threads:[~2023-04-05 12:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20 22:40 [6.2 regression][bisected]discard storm on idle since v6.1-rc8-59-g63a7cb130718 discard=async Christopher Price
2023-03-21 21:26 ` Josef Bacik
2023-03-22  8:38   ` Christoph Hellwig
2023-03-23 22:26     ` Sergei Trofimovich
2023-04-04 10:49       ` Linux regression tracking (Thorsten Leemhuis)
2023-04-04 16:04         ` Christoph Hellwig
2023-04-04 16:20           ` Roman Mamedov
2023-04-04 16:27             ` Christoph Hellwig
2023-04-04 23:37               ` Damien Le Moal
2023-04-04 18:15           ` Chris Mason
2023-04-04 18:51             ` Boris Burkov
2023-04-04 19:22               ` David Sterba
2023-04-04 19:39                 ` Boris Burkov
2023-04-05  8:17                   ` Linux regression tracking (Thorsten Leemhuis)
2023-04-10  2:03               ` Michael Bromilow
2023-04-11 17:52                 ` David Sterba
2023-04-11 18:15                   ` Linux regression tracking (Thorsten Leemhuis)
2023-04-04 19:08             ` Sergei Trofimovich
2023-04-05  6:18             ` Christoph Hellwig
2023-04-05 12:01               ` Chris Mason [this message]
2023-04-04 18:23         ` Boris Burkov
2023-04-04 19:12           ` Sergei Trofimovich
     [not found] <Y/+n1wS/4XAH7X1p@nz>
2023-03-02  8:04 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-04-04 10:52   ` Linux regression tracking #update (Thorsten Leemhuis)
2023-04-21 13:56   ` Linux regression tracking #update (Thorsten Leemhuis)
     [not found] ` <94cf49d0-fa2d-cc2c-240e-222706d69eb3@oracle.com>
     [not found]   ` <20230302105406.2cd367f7@nz>
2023-03-15 11:44     ` Linux regression tracking (Thorsten Leemhuis)
2023-03-15 16:34       ` Sergei Trofimovich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da8e4122-9e6a-fe4a-d064-30577a03ec00@meta.com \
    --to=clm@meta.com \
    --cc=anand.jain@oracle.com \
    --cc=boris@bur.io \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=hch@infradead.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=pricechrispy@gmail.com \
    --cc=regressions@lists.linux.dev \
    --cc=slyich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).