lkml.org 
[lkml]   [2001]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: fsck, raid reconstruction & bad bad 2.4.3
    Date
    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.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:25    [W:0.031 / U:0.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site