From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Organization: Dynacom Tankers Mgmt
To: pgsql-performance@postgresql.org
Subject: Re: Background fsck
Date: Fri, 8 Apr 2011 08:19:42 +0200
User-Agent: KMail/1.9.7
References: <4D9CEA3F.5050603@wp.pl>
	<201104071701.02647.achill@matrix.gatewaynet.com>
	<4D9EA367.7060102@wp.pl>
In-Reply-To: <4D9EA367.7060102@wp.pl>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201104080919.43152.achill@matrix.gatewaynet.com>

=CE=A3=CF=84=CE=B9=CF=82 Friday 08 April 2011 08:55:51 =CE=BF/=CE=B7 Ireneu=
sz Pluta =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
> Achilleas Mantzios wrote:
> >
> > In anyway, having FreeBSD to fsck, (background or not) should not happe=
n. And the problem
> > becomes bigger when cheap SATA drives will cheat about their write cach=
e being flushed to the disk.
> > So in the common case with cheap hardware, it is wise to have a UPS con=
nected and being monitored
> > by the system.
> >
>=20
> It's not lack of UPS. Power issues are taken care of here. It's a buggy 3=
ware controller which hangs=20
> the machine ocassionally and the only way to have it come back is to powe=
r cycle, hard reset is not=20
> enough.

What has happened to me (as Greg mentioned) is that repeatedly interrupted =
background fscks (having the system
crash while background fsck was executing) might result in a seriously dama=
ged fs.
Add to this, the possible overhead by rebuilding software raid (gmirror) at=
 the same time,
and the situation becomes more complicated.

So its better to replace/fix/remove this buggy controller, before anything =
else.

>=20
>=20


=2D-=20
Achilleas Mantzios