ÎÏÎÏ Thursday 07 April 2011 16:31:50 Î/Î Ivan Voras ÎÎÏÎÏÎ: > 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. > I agree with Ivan. In the case of background fsck ,there is absolutely no reason to postpone using postgresql, more than doing the same for any other service in the system. In anyway, having FreeBSD to fsck, (background or not) should not happen. And the problem becomes bigger when cheap SATA drives will cheat about their write cache being flushed to the disk. So in the common case with cheap hardware, it is wise to have a UPS connected and being monitored by the system. -- Achilleas Mantzios -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
