Message-ID: <4D9DE376.2090704@2ndQuadrant.com>
Date: Thu, 07 Apr 2011 12:16:54 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Background fsck
References: <4D9CEA3F.5050603@wp.pl>
In-Reply-To: <4D9CEA3F.5050603@wp.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 04/06/2011 06:33 PM, Ireneusz Pluta wrote:
> I saw some recommendations from people on the net not to use 
> background fsck when running PostgreSQL on FreeBSD. As I recall, these 
> opinions were just thoughts of people which they shared with the 
> community, following their bad experience caused by using background fsck.

Presumably you're talking about reports like these two:

http://blog.e-shell.org/266
http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074773.html

> 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 ask whether I really need to avoid background fsck on a PostgreSQL 
> machine?

The soft update code used in FreeBSD makes sure that there's no damage 
to the filesystem that PostgreSQL can't recover from.  Once the WAL is 
replayed after a crash, the database is consistent.  The main purpose of 
the background fsck is to find "orphaned" space, things that the 
filesystem incorrectly remembers the state of in regards to whether it 
was allocated and used.  In theory, there's no reason that can't happen 
in the background, concurrent with normal database activity.

In practice, background fsck is such an infrequently used piece of code 
that it's developed a bit of a reputation for being buggier than 
average.  It's really hard to test it, filesystem code is complicated, 
and the sort of inconsistent data you get after a hard crash is often 
really surprising.  I wouldn't be too concerned about the database 
integrity, but there is a small risk that background fsck will run into 
something unexpected and panic.  And that's a problem you're much less 
likely to hit using the more stable regular fsck code; thus the 
recommendations by some to avoid it.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books