Re: fsck, raid reconstruction & bad bad 2.4.3

["Jakob Østergaard" <jakob@unthought.net>]

On Sun, Apr 15, 2001 at 09:51:52PM -0500, Jesse Pollard wrote:
...
> 
> If I've got the numbering right;
> 	0 - concatenated stripes => no sync required
> 	1 - mirrored => resync required
> 		a: which drive has the correct info?

a: there are timestamps in the superblocks.  one disk is simply chosen as
   the "newest", and the other disks are updateed from that one.

> 		b: having determined that, read the correct block,
> 		   it must now be written to the mirror.
> 	all others => resync required (rebuild possible bad block)

If a resync is required, it is because we can derive the correct information
*without* having the array in sync  (resync puts correct information in places
where we know it's not currently correct).   fsck can never see "old" information,
no matter the state of the resync.  If it could, RAID would be broken.

Levels 1, 4 and 5 need a resync - but they all give you the correct
information even *before* resync.

Levels 0 and linear cannot be synced (and will fail if you pull a disk, all because
they do not have redundant information).   Talking about sync in these cases doesn't
make sense.

> 
> >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).

I think the problem is that RAID throttles based on bandwidth, not based on
requests.  If fsck needs a lot of seeking, the RAID code won't notice that
the array is being used much, and thus won't throttle a lot.

Also, even if fsck does large sequential reads, the RAID code may throttle,
but it will then introduce small frequent seeks to when it updates a few
blocks every now and then.  Seeks have a huge impact on otherwise sequential
reads.

> 
> 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).

Oh, do we resync blocks that are read ? I didn't know that actually...

This should give little overhead on RAID-1, since most reads would be done
on one disk and the "older disk" (the one being synced with information from
the newer one) would only be written to.

> 
> 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.
> 

If we resync RAID-1 blocks as they are read, I don't understand the claimed
performance impact of resync.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............: