linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Brad Campbell <brad@wasp.net.au>
Cc: mingz@ele.uri.edu, linux-raid@vger.kernel.org
Subject: Re: consistency detect
Date: Mon, 11 Oct 2004 14:42:58 +0400	[thread overview]
Message-ID: <416A63B2.7020004@tls.msk.ru> (raw)
In-Reply-To: <416A4A29.9080906@wasp.net.au>

Brad Campbell wrote:
> Ming Zhang wrote:
> 
>> I have a question on RAID error detect. hope somebody can help me to
>> find it out. thanks.
>>
>> take raid1 as an example, if one disk fail, raid 1 can detect the data
>> on disk is compromised and then reconstruct it using a spare disk. this
>> is straight forward.
>>
>> but if one request comes to raid1 and raid1 sends requests to both
>> disks, at this time, system reboots because power outage, system
>> crashes, or any other reason. then after system reboots, how raid 1
>> detects which disk has consistent data? since before reboot, anything
>> can happen, data may in disk1 but not in disk2, or in disk2 but not in
>> disk1, or not in both disks, or already on both disks.
>>
>> how raid1 or other raid code deal with this?
> 
> 
> In short, it does not deal with it at all. RAID will deal with a disk 
> failure, it has no guarantees about consistency on power failures, hard 
> lockups or other catastrophic events.

This is incorrect.  In-kernel raid code keeps track of arrays and
underlying disk state during write operations.  On clean shutdown,
when everything has been written, raid superblocks on all disks
gets updated to indicate this.  In case of unclean shutdown, raid
code will reconstruct older copies of data using most recent ones
(ie, from a disk which has most recent "events" value in superblock).
The same is done for all other raid levels (4, 5, 6), but onot for
raid0 for obvious reasons (as there's no R in raid0 per se).

> A UPS is cheap insurance against consistency issues in combination with 
> a journalling filesystem.

Well, it is another (albiet very good) layer of protection.

/mjt

  reply	other threads:[~2004-10-11 10:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-11  3:32 consistency detect Ming Zhang
2004-10-11  8:54 ` Brad Campbell
2004-10-11 10:42   ` Michael Tokarev [this message]
2004-10-11 10:58     ` Brad Campbell
2004-10-11 21:15       ` Ming Zhang
2004-10-11 23:23 ` Neil Brown
2004-10-12  0:05   ` Ming Zhang
2004-10-12  0:13     ` Neil Brown
2004-10-12  0:43       ` Ming Zhang

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=416A63B2.7020004@tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=brad@wasp.net.au \
    --cc=linux-raid@vger.kernel.org \
    --cc=mingz@ele.uri.edu \
    /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).