Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 8C5941337BD8 for ; Thu, 7 Apr 2011 10:32:25 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 83393-07 for ; Thu, 7 Apr 2011 13:32:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id 64F371337B2F for ; Thu, 7 Apr 2011 10:32:05 -0300 (ADT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q7pJc-0003ak-Bf for pgsql-performance@postgresql.org; Thu, 07 Apr 2011 15:32:04 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2011 15:32:04 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2011 15:32:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: Background fsck Date: Thu, 07 Apr 2011 15:31:50 +0200 Lines: 34 Message-ID: References: <4D9CEA3F.5050603@wp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201104/74 X-Sequence-Number: 43136 On 07/04/2011 00:48, Scott Marlowe wrote: > On Wed, Apr 6, 2011 at 4:33 PM, Ireneusz Pluta wrote: >> Hello, >> >> 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. 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 ask >> whether I really need to avoid background fsck on a PostgreSQL machine? >> Could I hear your opinions? AFAIK, the reason why background fsck has been discouraged when used with databases is because it uses disk bandwidth which may be needed by the application. If you are not IO saturated, then there is no particular reason why you should avoid it. > Shouldn't a journaling file system just come back up almost immediately? It's a tradeoff; UFS does not use journalling (at least not likely in the version the OP is talking about) but it uses "soft updates". It brings most of the benefits of journalling, including "instant up" after a crash without the double-write overheads (for comparison, see some PostgreSQL benchmarks showing that unjournaled ext2 can be faster than journaled ext3, since PostgreSQL has its own form of journaling - the WAL). The downside is that fsck needs to be run occasionally to cleanup non-critical dangling references on the file system - thus the "background fsck" mode in FreeBSD.