public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <jesse@cats-chateau.net>
To: Jonathan Lundell <jlundell@pobox.com>, linux-kernel@vger.kernel.org
Subject: Re: fsck, raid reconstruction & bad bad 2.4.3
Date: Sun, 15 Apr 2001 21:51:52 -0500	[thread overview]
Message-ID: <01041522295701.15046@tabby> (raw)
In-Reply-To: <E14oxbX-0000oM-00@sites.inka.de> <01041521302600.15046@tabby> <p05100b09b7000a8c3bc9@[207.213.214.34]>
In-Reply-To: <p05100b09b7000a8c3bc9@[207.213.214.34]>

On Sun, 15 Apr 2001, Jonathan Lundell wrote:
>At 9:23 PM -0500 2001-04-15, Jesse Pollard wrote:
>> >b) wait with fsck until rebuild is fixed
>>
>>Depends on your definition of "fixed". The most I can see to fix is
>>reduce the amount of continued update in favor of updating those blocks
>>being read (by fsck or anything else). This really ought to be a runtime
>>configuration option. If it is set to 0, then no automatic repair would
>>be done.
>
>The original post was referring to RAID 1; there's no repair necessary at
>the RAID level to give fsck the correct data. Seems to me the basic problem
>here is that the RAID re-sync is supposed to be throttling back to allow other
>activity to run, but that in the case of fsck the other activity is still
>slower by a large factor (compared to no RAID re-sync).

If I've got the numbering right;
	0 - concatenated stripes => no sync required
	1 - mirrored => resync required
		a: which drive has the correct info?
		b: having determined that, read the correct block,
		   it must now be written to the mirror.
	all others => resync required (rebuild possible bad block)

>Is this a pathological case because of the way fsck does business, or does
>the RAID re-sync affect any disk-bound process that severely?

My experience has been with hardware raid, and even then there has been
a 1-5% decrease in I/O during resync (not accurately measured - fsck took
longer, and then only when the channel is maxed out -- otherwise the 1-5% is
not visible; filesystem was 3 IRIX efs, spread across two raid luns).

fsck is particularly bad, since nearly every read instigates a write to
the mirror drive. Fsck can then modify the block and write it back, causing
two more writes; for a total of 3 writes for a read (worst case).

It does mean that when fsck finishes, MOST of the re-sync will be finished.
All of the metadata will be synced, and only file data blocks will remain.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

  reply	other threads:[~2001-04-16  3:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-15 18:18 fsck, raid reconstruction & bad bad 2.4.3 Linas Vepstas
     [not found] ` <9bcoph$1vj$1@ns1.clouddancer.com>
2001-04-15 19:59   ` Colonel
2001-04-16  1:14     ` Bernd Eckenfels
2001-04-16  2:23       ` Jesse Pollard
2001-04-16  2:38         ` Jonathan Lundell
2001-04-16  2:51           ` Jesse Pollard [this message]
2001-04-16 19:06             ` Jakob Østergaard
2001-04-16  4:03         ` Bernd Eckenfels
2001-04-16 14:16 ` fsck, raid reconstruction & bad bad 2.4.3 + some numbers Francois Romieu
2001-04-17 11:53 ` fsck, raid reconstruction & bad bad 2.4.3 Ookhoi
     [not found] <p05100b09b7000a8c3bc9@207.213.214.34>
2001-04-16  4:05 ` Bernd Eckenfels

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=01041522295701.15046@tabby \
    --to=jesse@cats-chateau.net \
    --cc=jlundell@pobox.com \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox