And it works great!
>The problem: this dramatically slows fsck after an unclean shut-down.
>You can hear the drives machine-gunning. I haven't stop-watch timed it,
>but its on the order of 5x slower to fsck a raid partition when there's
>reconstruction going on, then when the raid thinks its clean. This
>makes unclean reboots quite painful.
Since the alternative is to sit there and do NOTHING until the
reconstruction is complete, ala Solaris 2.5, it's WONDERFUL the way it
is. This change was extensively discussed on the raid mailing list a
couple of years ago. You can look it up for review.
>(There is no config file to disable/alter this .. no work-around that I
>know of ..)
You can't be serious. Go sit down and think about what's going on.
>--------
>The second problem: oparallelizing fsck doesn't realize that different
>/dev/md raid volumes are on the same physical disks, and thus tries
>to parallelize .... again slowing things down. There is a work-around,
>modify /etc/fstab to set the rder of fsck's. However, I doubt the HOWTO
>really gets into this .... it would be nice to get fsck to 'do the
>right thing'.
You probably have your fstab incorrectly setup.
<snip>
#> In particular, how does fsck deal with md devices? It parallelizes
#> itself for multiple disks, but if the volumes are all actually striped
#> over the same disks, fsck will perform better if it's serial.
#
#The "pass" field in /etc/fstab is for exactly this: fsck -a will
#serialise devices with different pass numbers. Pass==1 is for root,
#pass==2 is for normal devices which fsck knows how to serialise. If you
#want to force serialisation on md devices, use larger pass numbers.
</snip>
Do a little work, it won't hurt you. Fsck should not (and may not be
able to) decode metadevice structures.
Your third part was ignored, given the above.
-
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/