On 07/04/2011 00:48, Scott Marlowe wrote:
On Wed, Apr 6, 2011 at 4:33 PM, Ireneusz Pluta<ipluta@xxxxx> 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.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
