From: Roman Mamedov <rm@romanrm.net>
To: Chris Murphy <lists@colorremedies.com>
Cc: Brassow Jonathan <jbrassow@redhat.com>,
"linux-raid@vger.kernel.org Raid" <linux-raid@vger.kernel.org>,
NeilBrown <neilb@suse.de>
Subject: Re: Status of discard support in MD RAID
Date: Fri, 12 Sep 2014 15:39:15 +0600 [thread overview]
Message-ID: <20140912153915.473bc562@natsu> (raw)
In-Reply-To: <26CB8B36-9CD9-4EE0-BFF2-4B183DBDD033@colorremedies.com>
[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]
On Thu, 11 Sep 2014 18:46:04 -0600
Chris Murphy <lists@colorremedies.com> wrote:
> If it doesn't, a check check > md/sync_action will report mismatches in
> md/mismatch_cnt; and a repair will probably corrupt the volume.
At least with RAID1/10, why would it?
> and you can't do repair type scrubs.
If the FS issues TRIM on a certain region, by definition it no longer cares
about what's stored there (as it's is no longer in use by the FS). So even if
a repair ends up coping some data from one SSD to another, in effect changing
the contents of that region, this should not affect anything whatsoever from
the FS standpoint.
Technically perhaps that still counts as a "corruption", but not of anything
in the filesystem metadata or user data, just of unused regions. So not as
scary as it first sounds.
The only case where you'd run into problems with this, is if some apps expect
to read back zeroes on TRIM'ed regions, e.g. Qemu in the "detect-zeroes=unmap"
mode. But using that would be dangerous even on a single SSD with
non-deterministic TRIM, so mdraid changes nothing here.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-09-12 9:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 23:38 Status of discard support in MD RAID Brassow Jonathan
2014-09-12 0:46 ` Chris Murphy
2014-09-12 9:03 ` David Brown
2014-09-12 9:26 ` Brad Campbell
2014-09-15 3:50 ` NeilBrown
2014-09-12 9:39 ` Roman Mamedov [this message]
2014-09-13 20:19 ` Chris Murphy
2014-09-15 3:56 ` NeilBrown
2014-09-15 3:46 ` NeilBrown
2014-09-15 3:44 ` NeilBrown
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=20140912153915.473bc562@natsu \
--to=rm@romanrm.net \
--cc=jbrassow@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=neilb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).