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@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
