Re: Filesystem wedges caused by r251446
--IiQkvLGLJxajv8+M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jul 13, 2013 at 10:14:06AM +0200, Ian FREISLICH wrote:
> Konstantin Belousov wrote:
> > On Fri, Jul 12, 2013 at 11:34:18PM +0200, Ian FREISLICH wrote:
> > > (kgdb) print runningbufreq
> > > $1 =3D 1
> > > (kgdb) print runningbufspace
> > > $2 =3D 0
> > > (kgdb) print lorunningspace
> > > $3 =3D 4587520
> > > (kgdb) print hirunningspace
> > > $4 =3D 4194304
> >=20
> > This is extremely weird. The hirunningspace is less then lorunningspac=
e,
> > am I right ? This causes the runningbufspace machinery to never wake up
>=20
> Yes. This state of affairs doesn't happen on r251445 and further
> testing on my side shows it doesn't hapen on all my amd64 servers.
> It appears that this particular server type (Dell R200) running
> amd64 with geom_mirror is affected. I will have to test further
> by destroying the mirror and removing it from the kernel and see
> if I can still reproduce the issue. Perhaps r251446 exposes
> insufficient locking on opperations affecting these variables.
No. The lorunningspace is constant for the system lifetime.
It can only be changed by the sysctl vfs.lorunningspace.
Look into /etc/sysctl.conf or scripts which apply sysctl settings.
Boot the system single-user and show the
sysctl vfs.lorunningspace
sysctl vfs.hirunningspace
Compare the values from single user with the values after the system
booted normal.
>=20
> > I just verified on the 4G VM on amd64, my numbers for lo is 4587520,
> > for high 6881280. Verify your tuning and kernel options, which you sho=
uld
> > have provided with the original report, I think.
>=20
> Sorry about that (and I'm relieved:) I had originally compiled with
> CPUTYPE?=3Dopteron which is incorrect for this CPU. However the
> problem persists with CPUTYPE?=3Dcore2, but I'm not sure how much of
> a difference this makes with clang. Also, I have another affected
> host that's compiled with gcc and the correct CPUTYPE so I doubt
> it's the compiler.
>=20
This is irrelevant, CPU type cannot affect the calculation, unless the
compiler is horribly broken.
--IiQkvLGLJxajv8+M
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iQIcBAEBAgAGBQJR4SX5AAoJEJDCuSvBvK1BqYsP+gMJ/db3BzdxhYpPZlP3CmgX
xUz+cCtjTF0bLW6GgSV0Yd2aK4yHlanr38LmBAHUVuNXq5Mr9vvxhvebqCzyxrFq
ar3JiR3v6rMu0J6I0shIqGSrRJeY7ZsHPn/Tb1hGLzaqtdXzFxs5fS4QGhBjnaMZ
Mbg1zjNZjonSVkimFIhFSijklmRXfxIuihOi8bzpMmKWNW2ruYWb2kE9vHd7teEM
AaSLhfaqTnlpXyyR/yEpZPigyE/ksUrzHOHvUDu1pMdXqcxZYEeg9KXJSJz/ro8R
6rFvImmT8MGBv43arbup5AGJ12RGc0INkKXj1KGQrLpM/mVrpYPAkLHhtv0miIxp
Eymg/cUH13NYm9Et6pG7SQibE7leebmWYr6EIj63unM+H/wx2QVVJoUGJZHmUppF
j16KlhqL1A9xWHoUIMQH5hWtkst5luFX+0ItyJesVKMDn60ck81cyGyqt5xiI9yI
Xaw5zSK9RNC1Z4hXaTYmwkU7AvprX0s/hl9fuFW930TQYnYXP5/3PmkZyIgLAD8k
tUcNV81+Du3nXMarDx+7196gQiFP9Ynz8SyoLU7aDRdmf0XgeZFizzy9TEB0BEe9
NXvaJ/m6wUWua/a1tGq3vD/3kF5y8w9EgA2ZNXkHNIV2gUZsYYYtKXNC6B/6OWu9
QO48a4CuxkzgK7sL2bon
=xVOK
-----END PGP SIGNATURE-----
--IiQkvLGLJxajv8+M--
討論串 (同標題文章)
完整討論串 (本文為第 12 之 16 篇)：