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.
next prev parent 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