Re: fsync on ext4 does not work

From: Havasvölgyi Ottó <havasvolgyi(dot)otto(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: fsync on ext4 does not work
Date: 2011-12-22 10:32:28
Message-ID: CAOryeA3G4+ox3CDQ=xAJFYn50TZmPjOrax-VSk2wqfkvRXZ=2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I have run fsync_test on this partition, and I got 2500+ for all kind of
sync method.

dmesg says:
blkfront: xvde: barriers enabled
blkfront: xvda: barriers enabled

One thing I haven't mentioned yet, that this a VM virtualized with Xen.
Perhaps this has some effect.

Thanks,
Otto

2011/12/20 Greg Smith <greg(at)2ndquadrant(dot)com>

> On 12/19/2011 10:52 AM, Havasvölgyi Ottó wrote:
>
>> PgSql 9.1.2
>> Debian, 2.6.32 kernel
>> WAL filesystem: ext4 with defaults
>>
>
> There's a pg_test_fsync program included with the postgresql-contrib
> package that might help you sort out what's going on here. This will
> eliminate the possibility that you're doing something wrong with pgbench,
> and give an easy to interpret number relative to the drive RPM rate.
>
> You said default settings, which eliminated "nobarrier" as a cause here.
> The only other thing I know of that can screw up fsync here is using one
> of the incompatible LVM features to build your filesystem. I don't know
> which currently work and don't work, but last I checked there were a few
> ways you could set LVM up that would eliminate filesystem barriers from
> working properly. You might check:
>
> dmesg | grep barrier
>
> To see if you have any kernel messages related to this.
>
> Here's a pg_test_fsync example from a Debian system on 2.6.32 with ext4
> filesystem and 7200 RPM drive, default mount parameters and no LVM:
>
> $ ./pg_test_fsync
> 2000 operations per test
> O_DIRECT supported on this platform for open_datasync and open_sync.
>
> Compare file sync methods using one 8kB write:
> (in wal_sync_method preference order, except fdatasync
> is Linux's default)
> open_datasync n/a
> fdatasync 113.901 ops/sec
> fsync 28.794 ops/sec
> fsync_writethrough n/a
> open_sync 111.726 ops/sec
>
> Compare file sync methods using two 8kB writes:
> (in wal_sync_method preference order, except fdatasync
> is Linux's default)
> open_datasync n/a
> fdatasync 112.637 ops/sec
> fsync 28.641 ops/sec
> fsync_writethrough n/a
> open_sync 55.546 ops/sec
>
> Compare open_sync with different write sizes:
> (This is designed to compare the cost of writing 16kB
> in different write open_sync sizes.)
> 16kB open_sync write 111.909 ops/sec
> 8kB open_sync writes 55.278 ops/sec
> 4kB open_sync writes 28.026 ops/sec
> 2kB open_sync writes 14.002 ops/sec
> 1kB open_sync writes 7.011 ops/sec
>
> Test if fsync on non-write file descriptor is honored:
> (If the times are similar, fsync() can sync data written
> on a different descriptor.)
> write, fsync, close 28.836 ops/sec
> write, close, fsync 28.890 ops/sec
>
> Non-Sync'ed 8kB writes:
> write 112113.908 ops/sec
>
> --
> Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-general<http://www.postgresql.org/mailpref/pgsql-general>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2011-12-22 15:29:16 Re: Trying to understand postgres crash
Previous Message Shankar Palaniappan 2011-12-22 09:31:00 Unable to connect to PostgreSQL server : Could not get socket error status