Greg Smith wrote: > There are some known limitations to Linux fsync that I remain somewhat > concerned about, independantly of LVM, like "ext3 fsync() only does a > journal commit when the inode has changed" (see > http://kerneltrap.org/mailarchive/linux-kernel/2008/2/26/990504 ). The > way files are preallocated, the PostgreSQL WAL is supposed to function > just fine even if you're using fdatasync after WAL writes, which also > wouldn't touch the journal (last time I checked fdatasync was > implemented as a full fsync on Linux). Since the new ext4 is more Indeed it does. I wonder if there should be an optional fsync mode in postgres should turn fsync() into fchmod (fd, 0644); fchmod (fd, 0664); to work around this issue. For example this program below will show one write per disk revolution if you leave the fchmod() in there, and run many times faster (i.e. lying) if you remove it. This with ext3 on a standard IDE drive with the write cache enabled, and no LVM or anything between them. ========================================================== /* ** based on http://article.gmane.org/gmane.linux.file-systems/21373 ** http://thread.gmane.org/gmane.linux.kernel/646040 */ #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> int main(int argc,char *argv[]) { if (argc<2) { printf("usage: fs <filename>\n"); exit(1); } int fd = open (argv[1], O_RDWR | O_CREAT | O_TRUNC, 0666); int i; for (i=0;i<100;i++) { char byte; pwrite (fd, &byte, 1, 0); fchmod (fd, 0644); fchmod (fd, 0664); fsync (fd); } } ========================================================== -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
