linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: John Andre Taule <post@johnandre.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm raid 5 one disk overwritten file system failed
Date: Thu, 19 Feb 2015 18:15:04 +0100	[thread overview]
Message-ID: <20150219171504.GA8567@lazy.lzy> (raw)
In-Reply-To: <020601d04c17$08c10290$1a4307b0$@johnandre.net>

On Thu, Feb 19, 2015 at 08:38:19AM +0100, John Andre Taule wrote:
> Hi!
> 
> Case: mdadm Raid 5 4 2TB disks. ext4 formatted spanning the raid.
> Attack: dd if=/dev/zero of=/dev/sdb bs=1M
> 
> Expected result would be a raid that could be recovered without data loss.
> 
> Result was that the file system failed and not possible to recover. 
> 
> As I understand it if this was a "hardware type fake" raid controller, the
> outcome would be uncertain. However I'm a bit confused as to why the raid
> (or more specifically the file system) would fail so horrible when losing
> one disk. Is there perhaps critical information written "outside" the raid
> on the physical disk, and this where overwritten in the attack?
> 
> It would be nice to have an exact idea as to why it failed so hard, and how
> obvious it should be that this attack would have more consequence then a
> degraded raid.

In this situation, there is no HDD failure.
The kernel, the md driver, the sata driver and so on,
cannot detect any failure, because there is none.
The HDD is alive and kicking and well writing.

Just to be clear and avoid confusion, the (redundant)
RAID does *not* check, at each read operation, that
the data is consistent. It does only use redundancy
in order to re-generate missing data *after* a failure
is detected.

So, writing to a RAID component does not trigger any
error, hence no failure, hence no reconstruction, but
a corrupted filesystem.

bye,

pg

> 
> //Regards
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

piergiorgio

      parent reply	other threads:[~2015-02-19 17:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19  7:38 mdadm raid 5 one disk overwritten file system failed John Andre Taule
2015-02-19 11:20 ` Mikael Abrahamsson
2015-02-19 14:00   ` SV: " John Andre Taule
2015-02-19 14:23     ` Mikael Abrahamsson
2015-02-19 14:39       ` Adam Goryachev
2015-02-19 16:21         ` SV: " John Andre Taule
2015-02-19 22:15         ` Wols Lists
2015-04-15 11:47       ` SV: " John Andre Taule
2015-04-15 12:38         ` Mikael Abrahamsson
2015-04-15 18:27           ` Wols Lists
2015-02-19 17:15 ` Piergiorgio Sartor [this message]

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=20150219171504.GA8567@lazy.lzy \
    --to=piergiorgio.sartor@nexgo.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=post@johnandre.net \
    /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).