Re: Maximum transaction rate

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Marco Colombo <pgsql(at)esiway(dot)net>
Cc: "pgsql-general(at)postgresql(dot)org >> Postgres general mailing list" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Maximum transaction rate
Date: 2009-03-19 15:54:18
Message-ID: 1237478058.21112.2.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Brian Ghidinelli 2009-03-19 16:05:15 Re: [GENERAL] Re: [pgsql-advocacy] Video from the 2009-03-11 SFPUG talk on Unison, by Reese Hart
Previous Message Shane Ambler 2009-03-19 15:34:14 Re: PostgreSQL versus MySQL for GPS Data