From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: Shaohua Li <shli@kernel.org>
Cc: linux-raid@vger.kernel.org, jes.sorensen@gmail.com, neilb@suse.de
Subject: Re: RAID creation resync behaviors
Date: Thu, 4 May 2017 09:55:51 +0200 [thread overview]
Message-ID: <20170504075551.GA3929@metamorpher.de> (raw)
In-Reply-To: <20170504022258.eov6xh2zwtbfvcch@kernel.org>
On Wed, May 03, 2017 at 07:22:58PM -0700, Shaohua Li wrote:
>
> Unfortunately not all SSD return zero after trim.
>
For example? I was under the impression that pretty much all of them do.
Even the ones that don't advertize it returned zero after trim for me.
[Sometimes you get original data but that's Linux; gone after drop_caches]
(Of course, I don't have access to that many different models of SSD...)
But what do they actually return then? Original data? This might seem
fine at first but it can't be the case, right? I mean, even if the SSD
does not erase a trimmed block right away, sooner or later it would,
in order to re-use it for new data and wear leveling. If it's never
re-used what is the point of trimming it in the first place?
So it seems to me even if an SSD attempted to keep returning original data
for a while, sooner or later it would be gone and if that happens randomly,
as far as your RAID is concerned you will be in mismatch hell anyways.
So after a full trim, you can skip the initial sync either way.
Mismatches might also be an issue for SSD that do return zero after trim,
but have different erase block sizes / trim boundaries / partition offsets.
Or does read zero after trim actually mean it works at 4K page resolution?
Never mind, then. :-)
Regards
Andreas Klauer
next prev parent reply other threads:[~2017-05-04 7:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 20:27 RAID creation resync behaviors Shaohua Li
2017-05-03 21:06 ` David Brown
2017-05-04 1:54 ` Shaohua Li
2017-05-04 7:37 ` David Brown
2017-05-04 16:02 ` Wols Lists
2017-05-04 21:57 ` NeilBrown
2017-05-05 6:46 ` David Brown
2017-05-04 15:50 ` Wols Lists
2017-05-04 22:00 ` NeilBrown
2017-05-03 23:58 ` Andreas Klauer
2017-05-04 2:22 ` Shaohua Li
2017-05-04 7:55 ` Andreas Klauer [this message]
2017-05-04 8:06 ` Roman Mamedov
2017-05-04 15:20 ` Brad Campbell
2017-05-04 1:07 ` NeilBrown
2017-05-04 2:04 ` Shaohua Li
2017-05-09 18:39 ` Jes Sorensen
2017-05-09 20:30 ` NeilBrown
2017-05-09 20:49 ` Jes Sorensen
2017-05-09 21:03 ` Martin K. Petersen
2017-05-09 21:11 ` Jes Sorensen
2017-05-09 21:16 ` Martin K. Petersen
2017-05-09 21:22 ` Jes Sorensen
2017-05-09 23:56 ` Martin K. Petersen
2017-05-10 5:58 ` Hannes Reinecke
2017-05-10 22:20 ` Martin K. Petersen
2017-05-10 17:30 ` Shaohua Li
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=20170504075551.GA3929@metamorpher.de \
--to=andreas.klauer@metamorpher.de \
--cc=jes.sorensen@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=shli@kernel.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.