Thread: Linux Filesystems again - Ubuntu this time
I'm involved with the setup of replacement hardware for one of our systems. It is going to be using Ubuntu Lucid Server (kernel 2.6.32 I believe). The issue of filesystems has raised its head again. I note that ext4 is now the default for Lucid, what do folks think about using it: stable enough now? Also xfs has seen quite a bit of development in these later kernels, any thoughts on that? Cheers Mark P.s: We are quite keen to move away from ext3, as we have encountered its tendency to hit a wall under heavy load and leave us waiting for kjournald and pdflush to catch up....
Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote: > Also xfs has seen quite a bit of development in these later > kernels, any thoughts on that? We've been using xfs for a few years now with good performance and no problems other than needing to disable write barriers to get good performance out of our battery-backed RAID adapter. -Kevin
Kevin, While we're on the topic, do you also diable fsync? We use xfs with battery-backed raid as well. We have had no issues with xfs. I'm curious whether anyone can comment on his experience (good or bad) using xfs/battery-backed-cache/fsync=off. Thanks, Whit On Tue, Jul 27, 2010 at 9:48 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote: > >> Also xfs has seen quite a bit of development in these later >> kernels, any thoughts on that? > > We've been using xfs for a few years now with good performance and > no problems other than needing to disable write barriers to get good > performance out of our battery-backed RAID adapter. > > -Kevin > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >
Whit Armstrong <armstrong.whit@gmail.com> wrote: > While we're on the topic, do you also diable fsync? We only disable fsync during bulk loads, where we would be starting over anyway if there was a failure. Basically, you should never use fsync unless you are OK with losing everything in the database server if you have an OS or hardware failure. We have a few databases where we would consider that if performance wasn't otherwise acceptable, since they are consolidated replicas of off-side source databases, and we have four identical ones in two separate buildings; however, since performance is good with fsync on and it would be a bother to have to copy from one of the other servers in the event of an OS crash, we leave it on. -Kevin
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > Basically, you should never use fsync unless you are OK with > losing everything in the database server if you have an OS or > hardware failure. s/use/disable/ -Kevin
Thanks. But there is no such risk to turning off write barriers? I'm only specifying noatime for xfs at the moment. Did you get a substantial performace boost from disabling write barriers? like 10x or more like 2x? Thanks, Whit On Tue, Jul 27, 2010 at 1:19 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > >> Basically, you should never use fsync unless you are OK with >> losing everything in the database server if you have an OS or >> hardware failure. > > s/use/disable/ > > -Kevin >
Whit Armstrong <armstrong.whit@gmail.com> wrote: > But there is no such risk to turning off write barriers? Supposedly not: http://xfs.org/index.php/XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.3F > Did you get a substantial performace boost from disabling write > barriers? like 10x or more like 2x? It made a huge difference on creation and deletion of disk files. Unfortunately we have some procedures which use a cursor and loop through rows calling a function which creates and drops a temporary table. While I would like to see those transactions rewritten to use sane techniques, they run fast enough without the write barriers to be acceptable to the users, which puts the issue pretty low on the priority list. I don't have the numbers anymore, but I'm sure it was closer to 100 times slower than 10 times. In some workloads you might not notice the difference, although I would watch out for checkpoint behavior. -Kevin