From: Peter Wu <peter-VTkQYDcBqhK7DlmcbJSQ7g@public.gmane.org>
To: Tim Small <tim-v0yPK6tSSg/10XsdtD+oqA@public.gmane.org>
Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: blkdiscard vs hdparm for erasing a SSD?
Date: Thu, 16 Oct 2014 12:17:38 +0200 [thread overview]
Message-ID: <1471878.ajvL24Q1JG@al> (raw)
In-Reply-To: <543E82DE.8070405-v0yPK6tSSg/10XsdtD+oqA@public.gmane.org>
On Wednesday 15 October 2014 15:21:18 Tim Small wrote:
> On 15/10/14 14:12, Peter Wu wrote:
> > [ blkdiscard vs hdparm --security-erase] How does this compare. The goal is
> > to erase the contents of an previously used SSD to improve performance.
> >
>
> When you use blkdiscard, the SSD (assuming a SATA SSD) will receive an
> ATA TRIM command, whereas hdparm --security-erase will issue an ATA
> SECURITY ERASE UNIT command.
>
> What the drive then actually does is dependant on the implementation
> details of that particular SSD's firmware.
>
> In general, I would expect the performance gain from TRIMing the entire
> drive to be either the same-as, or possibly less-than the gain from
> SECURITY ERASE. For a sane firmware implementation I'd expect them to
> have the same effect on performance. Firmware implementations are not
> always sane.
The names suggest that TRIM is for marking sectors for garbage collection while
SECURITY ERASE tries a bit harder. From the runtime performance point of view, I
would expect that S.E. is at least as fast as TRIM as no more garbage needs to
be collected at a later point. From a durability PoV, not so sure, it could be
that S.E. overwrites all blocks (or not).
Anyway, I have not read into the details and unless the standards (and
manufacturers) can guarantee certain behavior, it will likely vary between
device models.
Thank you for your reply!
--
Kind regards,
Peter
https://lekensteyn.nl
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Peter Wu <peter@lekensteyn.nl>
To: Tim Small <tim@seoss.co.uk>
Cc: linux-ide@vger.kernel.org, util-linux@vger.kernel.org
Subject: Re: blkdiscard vs hdparm for erasing a SSD?
Date: Thu, 16 Oct 2014 12:17:38 +0200 [thread overview]
Message-ID: <1471878.ajvL24Q1JG@al> (raw)
In-Reply-To: <543E82DE.8070405@seoss.co.uk>
On Wednesday 15 October 2014 15:21:18 Tim Small wrote:
> On 15/10/14 14:12, Peter Wu wrote:
> > [ blkdiscard vs hdparm --security-erase] How does this compare. The goal is
> > to erase the contents of an previously used SSD to improve performance.
> >
>
> When you use blkdiscard, the SSD (assuming a SATA SSD) will receive an
> ATA TRIM command, whereas hdparm --security-erase will issue an ATA
> SECURITY ERASE UNIT command.
>
> What the drive then actually does is dependant on the implementation
> details of that particular SSD's firmware.
>
> In general, I would expect the performance gain from TRIMing the entire
> drive to be either the same-as, or possibly less-than the gain from
> SECURITY ERASE. For a sane firmware implementation I'd expect them to
> have the same effect on performance. Firmware implementations are not
> always sane.
The names suggest that TRIM is for marking sectors for garbage collection while
SECURITY ERASE tries a bit harder. From the runtime performance point of view, I
would expect that S.E. is at least as fast as TRIM as no more garbage needs to
be collected at a later point. From a durability PoV, not so sure, it could be
that S.E. overwrites all blocks (or not).
Anyway, I have not read into the details and unless the standards (and
manufacturers) can guarantee certain behavior, it will likely vary between
device models.
Thank you for your reply!
--
Kind regards,
Peter
https://lekensteyn.nl
next prev parent reply other threads:[~2014-10-16 10:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 13:12 blkdiscard vs hdparm for erasing a SSD? Peter Wu
2014-10-15 13:12 ` Peter Wu
2014-10-15 14:21 ` Tim Small
[not found] ` <543E82DE.8070405-v0yPK6tSSg/10XsdtD+oqA@public.gmane.org>
2014-10-16 10:17 ` Peter Wu [this message]
2014-10-16 10:17 ` Peter Wu
2014-10-21 17:06 ` One Thousand Gnomes
2014-10-21 17:06 ` One Thousand Gnomes
2014-10-28 2:09 ` Mark Lord
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=1471878.ajvL24Q1JG@al \
--to=peter-vtkqydcbqhk7dlmcbjsq7g@public.gmane.org \
--cc=linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tim-v0yPK6tSSg/10XsdtD+oqA@public.gmane.org \
--cc=util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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.