All of lore.kernel.org
 help / color / mirror / Atom feed
From: charlesfdotz@tutanota.com
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>, Dm Devel <dm-devel@lists.linux.dev>
Subject: Re: Feature Request: Device Manager Fake Trim / Zero Trim
Date: Tue, 10 Oct 2023 16:31:56 +0200 (CEST)	[thread overview]
Message-ID: <NgP-4zc--7-9@tutanota.com> (raw)
In-Reply-To: <dc7c0122-8077-4aa5-87e6-87404f48a4ce@kernel.org>


Oct 10, 2023, 06:48 by dlemoal@kernel.org:

> On 10/9/23 15:15, Hannes Reinecke wrote:
>
>> On 10/9/23 02:56, charlesfdotz@tutanota.com wrote:
>>
>>> Hello,
>>>
>>> I would like to request a new device manager layer be added that accepts
>>> trim requests for sectors and instead writes zeros to those sectors.
>>>
>>> This would be useful to deal with SMR (shingled magnetic recording) drives
>>> that do not support trim. Currently after an SMR drive has had enough data
>>> written to it the performance drops dramatically because the disk must 
>>> shuffle around data as if it were full and without trim support there is no
>>> way to inform the disk which sectors are no longer used. Currently there's
>>> no way to "fix" or reset this without doing an ATA secure erase despite 
>>> many of these disk being sold without informing customers that they were
>>> SMR drives (western digital was sued for selling SMR drives as NAS
>>> drives).
>>>
>> Gosh, no, please don't. SMR drives have a write pointer, and if the zone
>> needs to be reset you just reset the write pointer. Writing zeroes will
>> result in the opposite; the zone continues to be full, and no writes can
>> happen there.
>>
>
> Yes. And zone reset *is* a trim also since after a zone reset, the sectors in
> the zone cannot be read.
>
>> Which drive is this?
>>
>
> From reading the description of the "issue", it seems that this is related to
> drive managed SMR disks, which may or may not be detectable from the host (if
> the drive is honest and reports it, the scsi_disk zoned_cap attribute will say
> "drive-managed"). So no zone reset for a drive managed SMR disk since they are
> "normal" drives from the interface perspective.
>
> A drive managed SMR disk may or may not benefit from TRIM. That completely
> depends on the device internal implementation to handle the SMR constraint. If
> the drive does not have trim/discard support, it is likely because that serves
> no purpose or would be useless performance-wise...
>
> -- 
> Damien Le Moal
> Western Digital Research
>
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

Oct 10, 2023, 06:53 by dlemoal@kernel.org:

> On 10/10/23 01:25, > charlesfdotz@tutanota.com>  wrote:
>
>>
>> Oct 9, 2023, 09:43 by >> mpatocka@redhat.com>> :
>>
>>>
>>>
>>> On Mon, 9 Oct 2023, Hannes Reinecke wrote:
>>>
>>>> On 10/9/23 02:56, >>>> charlesfdotz@tutanota.com>>>>  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I would like to request a new device manager layer be added that
>>>>> accepts trim requests for sectors and instead writes zeros to those
>>>>> sectors.
>>>>>
>>>>> This would be useful to deal with SMR (shingled magnetic recording)
>>>>> drives that do not support trim. Currently after an SMR drive has had
>>>>> enough data written to it the performance drops dramatically because
>>>>> the disk must shuffle around data as if it were full and without trim
>>>>> support there is no way to inform the disk which sectors are no longer
>>>>> used. Currently there's no way to "fix" or reset this without doing an
>>>>> ATA secure erase despite many of these disk being sold without
>>>>> informing customers that they were SMR drives (western digital was
>>>>> sued for selling SMR drives as NAS drives).
>>>>>
>>>> Gosh, no, please don't. SMR drives have a write pointer, and if the zone
>>>> needs to be reset you just reset the write pointer. Writing zeroes will
>>>> result in the opposite; the zone continues to be full, and no writes can
>>>> happen there.
>>>>
>>>> Which drive is this?
>>>>
>>>> Cheers,
>>>>
>>>> Hannes
>>>>
>> The drive in the link is a ST8000DM004-2CX188 according to the poster. To be
>> clear I'm talking about device managed SMR drives that don't support trim and
>> do not report being SMR *not* host aware drives. The DM-SMR drives work fine
>> until you've written their total capacity once then the write performance
>> craters permanently because the drive thinks all the data on it is important
>> and has to reshuffle it constantly during writes. We are talking sub-1MiB/s
>> and hangs waiting on the controller to move things around that can be several
>> minutes. WD was recently sued for selling some of these as "WD Red NAS"
>> drives.
>>
>> I'm not sure why writing zeros appears to work so this just speculation on my
>> part but I was thinking the drive might be smart enough to mark sectors full
>> of zeros as unused and then return any request for an unused sector as zeros.
>>
>
> If the drive does not even support trim/discard, thinking it has such
> intelligence is a long shot... I would not bet on it :)
>
>>>
>>> BTW. what about converting trims to zone reset? If the trim spans a whole
>>> zone, the kernel could convert it to REQ_OP_ZONE_RESET on host-aware zoned
>>> devices.
>>>
>>> Mikulas
>>>
>> This particular request was to try and make (some) device managed SMR drives
>> that don't report to the host that they are SMR more usable. I was thinking
>> if they are a model where zero sectors appear to "trim" one could just put
>> this "fake-trim" device mapper layer over it and then it would act like a
>> device managed SMR drive that supports trim.
>>
>
> Check /sys/block/sdX/device/scsi_disk/xxxx/zoned_cap. Does it say "drive-managed" ?
>
> I do not think that writing zeroes will help in any way. Drives do not generally
> (as far as I know) look at the data they are reading/writing to try to be smart.
> Writing zeroes is the same as writing random bytes. For a good reason: sometimes
> initializing sectors to contain zeroes *is* important !
>
> --
> Damien Le Moal
> Western Digital Research
>
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.

Sincerely,
Chuck

  parent reply	other threads:[~2023-10-10 14:32 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 [this message]
2023-10-11  0:33       ` Damien Le Moal
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=NgP-4zc--7-9@tutanota.com \
    --to=charlesfdotz@tutanota.com \
    --cc=dlemoal@kernel.org \
    --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.