Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Aug 2004 09:33:56 +0200
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        freebsd-arch@FreeBSD.org
Subject:   Re: Mounting root...
Message-ID:  <20040825073356.GG30151@darkness.comp.waw.pl>
In-Reply-To: <200408240943.40529.jhb@FreeBSD.org>
References:  <20040823073559.GP30151@darkness.comp.waw.pl> <200408231716.31321.jhb@FreeBSD.org> <20040823214729.GX30151@darkness.comp.waw.pl> <200408240943.40529.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--ppsIhpb1zLTQE1OE
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 24, 2004 at 09:43:40AM -0400, John Baldwin wrote:
+> The fact that a RAID can recover when a disk goes away and comes back is=
=20
+> already the "general solution" it seems.  It works all the time, not jus=
t at=20
+> boot, so it seems to me like you are trying to solve a problem that is=
=20
+> already solved.  I think at most you could maybe have a system wide dela=
y=20
+> before that the user can tweak via a tunable (rather than a per-GEOM cla=
ss=20
+> tunable like your mirror one) in order to optimize the boot code for the=
se=20
+> rare cases but that is about it.  I.e., if a user notices that one of th=
e=20
+> disks always takes an extra second they can set the tunable to force the=
=20
+> kernel to wait 2 seconds before trying to mount root.  Any such delay sh=
ould=20
+> be centralized, however, and not per-class, since all the per-class dela=
ys=20
+> would end up being cumulative, so if MIRROR waits 2 seconds and STRIPE w=
aits=20
+> 3 seconds then the entire process actually waits 5 seconds as opposed to=
=20
+> letting the user tweak a single centralized timeout.

I second this, I'll prepare a patch then.

--=20
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

--ppsIhpb1zLTQE1OE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFBLEDkForvXbEpPzQRAqFdAKDgtCjtElPlFBXephoHyAc06/uNfgCeJYwm
1Rla7fjyOi4oBsFbA+a5OEQ=
=hUo8
-----END PGP SIGNATURE-----

--ppsIhpb1zLTQE1OE--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040825073356.GG30151>