From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Organization: Dynacom Tankers Mgmt
To: pgsql-performance@postgresql.org
Subject: Re: Background fsck
Date: Thu, 7 Apr 2011 16:01:02 +0200
User-Agent: KMail/1.9.7
References: <4D9CEA3F.5050603@wp.pl>
	<BANLkTim3SY4-P1xzxxfjB9BpvARfWd-Awg@mail.gmail.com>
	<inkec6$ful$1@dough.gmane.org>
In-Reply-To: <inkec6$ful$1@dough.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201104071701.02647.achill@matrix.gatewaynet.com>

=CE=A3=CF=84=CE=B9=CF=82 Thursday 07 April 2011 16:31:50 =CE=BF/=CE=B7 Ivan=
 Voras =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
> On 07/04/2011 00:48, Scott Marlowe wrote:
> > On Wed, Apr 6, 2011 at 4:33 PM, Ireneusz Pluta<ipluta@wp.pl>  wrote:
> >> Hello,
> >>
> >> I saw some recommendations from people on the net not to use backgroun=
d fsck
> >> when running PostgreSQL on FreeBSD. As I recall, these opinions were j=
ust
> >> thoughts of people which they shared with the community, following the=
ir bad
> >> experience caused by using background fsck. So, not coming any deeper =
with
> >> underatanding why not, I use that as a clear recommendation for myself=
 and
> >> keep background fsck turned off on all my machines, regardless how much
> >> faster a server could come up after a crash.
> >>
> >> But waiting so much time (like now) during foreground fsck of a large =
data
> >> filesystem after unclean shutdown, makes me to come to this group to a=
sk
> >> whether I really need to avoid background fsck on a PostgreSQL machine?
> >> Could I hear your opinions?
>=20
> AFAIK, the reason why background fsck has been discouraged when used=20
> with databases is because it uses disk bandwidth which may be needed by=20
> the application. If you are not IO saturated, then there is no=20
> particular reason why you should avoid it.
>=20
> > Shouldn't a journaling file system just come back up almost immediately?
>=20
> It's a tradeoff; UFS does not use journalling (at least not likely in=20
> the version the OP is talking about) but it uses "soft updates". It=20
> brings most of the benefits of journalling, including "instant up" after=
=20
> a crash without the double-write overheads (for comparison, see some=20
> PostgreSQL benchmarks showing that unjournaled ext2 can be faster than=20
> journaled ext3, since PostgreSQL has its own form of journaling - the=20
> WAL). The downside is that fsck needs to be run occasionally to cleanup=20
> non-critical dangling references on the file system - thus the=20
> "background fsck" mode in FreeBSD.
>=20

I agree with Ivan. In the case of background fsck ,there is absolutely no r=
eason to=20
postpone using postgresql, more than doing the same for any other service i=
n the system.

In anyway, having FreeBSD to fsck, (background or not) should not happen. A=
nd the problem
becomes bigger when cheap SATA drives will cheat about their write cache be=
ing flushed to the disk.
So in the common case with cheap hardware, it is wise to have a UPS connect=
ed and being monitored
by the system.

=2D-=20
Achilleas Mantzios