From: Roman Mamedov <rm@romanrm.net>
To: Remi Gauvin <remi@georgianit.com>
Cc: Chris Mason <clm@fb.com>, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: weekly fstrim (still) necessary?
Date: Sat, 27 Jun 2020 01:49:12 +0500 [thread overview]
Message-ID: <20200627014912.262647f2@natsu> (raw)
In-Reply-To: <5bf091c5-b769-b865-c1ab-4437565961d3@georgianit.com>
On Fri, 26 Jun 2020 16:18:03 -0400
Remi Gauvin <remi@georgianit.com> wrote:
> I'm probably just confusing the terminology... But could this be related
> to the queued trim problems with Samsung for which they should be
> blakclisted?
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81
A Samsung 860 SSD that I have is the worst (compared to a dozen non-Samsung
ones) when it comes to TRIM, NCQ, combination thereof, and compatibility with
various SATA controllers.
However it should be noted that while the commit referenced is not in the
mainline kernel anymore, a narrower blacklist applying to 840 and 850 models
currently is [1]. And as the report is about the 850 Pro, queued TRIM should
not have been the cause, as is already blacklisted in kernel for all "Samsung
SSD 850". Can check in 'dmesg' for a note about it shortly after the SSD
detection to confirm.
[1]
https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c#L3952
--
With respect,
Roman
next prev parent reply other threads:[~2020-06-26 20:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-21 5:42 weekly fstrim (still) necessary? Ulli Horlacher
2020-06-21 7:01 ` Andrei Borzenkov
2020-06-21 16:24 ` Lukas Tribus
2020-06-21 18:19 ` Adam Borowski
2020-06-21 19:39 ` Chris Murphy
2020-06-21 23:52 ` Ulli Horlacher
2020-06-21 23:57 ` Chris Murphy
2020-06-22 0:06 ` Ulli Horlacher
2020-06-22 0:57 ` Chris Murphy
2020-06-22 14:02 ` Ulli Horlacher
2020-06-22 14:23 ` David Sterba
2020-06-22 15:56 ` Chris Mason
2020-06-26 12:08 ` Fwd: " Tim Cuthbertson
2020-06-26 15:40 ` Chris Mason
2020-06-26 16:40 ` Chris Murphy
2020-06-26 16:48 ` Chris Mason
2020-06-26 19:32 ` Tim Cuthbertson
[not found] ` <CAAKzf7kMFqkrQyRzJ6WHVE95PBm2e0BX+QBua-2-rasp=BR7FQ@mail.gmail.com>
2020-06-26 19:33 ` Fwd: " Tim Cuthbertson
[not found] ` <00D64498-C734-4D08-8FBE-019B7292BE8E@fb.com>
2020-06-26 19:52 ` Tim Cuthbertson
2020-06-26 20:18 ` Remi Gauvin
2020-06-26 20:49 ` Roman Mamedov [this message]
2020-06-27 12:13 ` Jan Killius
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=20200627014912.262647f2@natsu \
--to=rm@romanrm.net \
--cc=clm@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=remi@georgianit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.