Bruce Momjian wrote: >> For example, ext3 fsync() will issue write barrier commands >> if the inode was modified; but not if the inode wasn't. >> >> See test program here: >> http://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg272253.html >> and read two paragraphs further to see how touching >> the inode makes ext3 fsync behave differently. > > I thought our only problem was testing the I/O subsystem --- I never > suspected the file system might lie too. That email indicates that a > large percentage of our install base is running on unreliable file > systems --- why have I not heard about this before? It came up a on these lists a few times in the past. Here's one example. http://archives.postgresql.org/pgsql-performance/2008-08/msg00159.php As far as I can tell, most of the threads ended with people still suspecting lying hard drives. But to the best of my ability I can't find any drives that actually lie when sent the commands to flush their caches. But various combinations of ext3 & linux MD that decide not to send IDE FLUSH_CACHE_EXT (nor the similiar SCSI SYNCHRONIZE CACHE command) under various situations. I wonder if there are enough ext3 users out there that postgres should touch the inodes before doing a fsync. > Do the write barriers allow data loss but prevent data inconsistency? If I understand right, data inconsistency could occur too. One aspect of the write barriers is flushing a hard drive's caches. > It sound like they are effectively running with synchronous_commit = off. And with the (mythical?) hard drive with lying caches. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
