Hello, As a continued follow up to this thread, Tim Post replied on the LVM list to this affect: " If a logical volume spans physical devices where write caching is enabled, the results of fsync() can not be trusted. This is an issue with device mapper, lvm is one of a few possible customers of DM. Now it gets interesting: Enter virtualization. When you have something like this: fsync -> guest block device -> block tap driver -> CLVM -> iscsi -> storage -> physical disk. Even if device mapper passed along the write barrier, would it be reliable? Is every part of that chain going to pass the same along, and how many opportunities for re-ordering are presented in the above? So, even if its fixed in DM, can fsync() still be trusted? I think, at the least, more testing should be done with various configurations even after a suitable patch to DM is merged. What about PGSQL users using some kind of elastic hosting? Given the craze in 'cloud' technology, its an important question to ask (and research). Cheers, --Tim " Joshua D. Drake -- PostgreSQL - XMPP: jdrake@xxxxxxxxxxxxxxxxxxxxx Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
