From: Damien Le Moal <dlemoal@kernel.org>
To: charlesfdotz@tutanota.com
Cc: Hannes Reinecke <hare@suse.de>, Dm Devel <dm-devel@lists.linux.dev>
Subject: Re: Feature Request: Device Manager Fake Trim / Zero Trim
Date: Wed, 11 Oct 2023 09:33:16 +0900 [thread overview]
Message-ID: <64e727f6-edcf-4b61-a2de-cb36d971fa2a@kernel.org> (raw)
In-Reply-To: <NgP-4zc--7-9@tutanota.com>
On 10/10/23 23:31, charlesfdotz@tutanota.com wrote:
> As I've said in all of my emails this is regarding drive-managed SMR disks that do no support trim. Most of these aren't detectable by the host because if there were then people wouldn't buy them as they're not fit for purpose. Western digital was sued over this and lost.
> https://arstechnica.com/gadgets/2020/05/western-digital-gets-sued-for-sneaking-smr-disks-into-its-nas-channel/
> https://www.tomshardware.com/news/wd-red-smr-lawsuit-pays-out-pennies-in-settlement-damages
There is no need to name names or point fingers here. Kernel open source
development is vendor agnostic and while my employer is indeed Western Digital,
I do not talk as a representative of WD products but as a kernel developer. So
calm down please if you want to keep the discussion open.
> You can opine that this unlikely but we have reports (which I've already linked) that this works on some SMR drives. It's also pretty ironic someone from western digital of all places is saying drives wouldn't lie about how they function so they must be writing zeros when told to.
Again, the finger pointing here is totally inappropriate. My points are all in
good faith and I am talking about the drives I know of.
In any case, the key-word in your statement is "some drives". Given that you are
talking about something that is not standardized and so cannot be safely
generalized, there is nothing we can do. It is a hard NO from me to replace the
lack of trim support with writing zeroes.
>
> Sincerely,
> Chuck
>
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2023-10-11 0:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 0:56 Feature Request: Device Manager Fake Trim / Zero Trim charlesfdotz
2023-10-09 6:15 ` Hannes Reinecke
2023-10-09 9:42 ` Mikulas Patocka
2023-10-09 16:25 ` charlesfdotz
2023-10-10 6:53 ` Damien Le Moal
2023-10-10 6:48 ` Damien Le Moal
2023-10-10 7:15 ` Hannes Reinecke
2023-10-10 7:46 ` Damien Le Moal
2023-10-10 14:31 ` charlesfdotz
2023-10-11 0:33 ` Damien Le Moal [this message]
2023-10-11 19:07 ` charlesfdotz
2023-10-12 4:22 ` Christoph Hellwig
2023-10-12 6:33 ` Hannes Reinecke
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=64e727f6-edcf-4b61-a2de-cb36d971fa2a@kernel.org \
--to=dlemoal@kernel.org \
--cc=charlesfdotz@tutanota.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.de \
/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.