On Mon, 16 Mar 2009, Marco Colombo wrote:
> >> No, it's more than that. PostgreSQL gurus say LVM doesn't honor fsync(),
> >> that data doesn't even get to the controller, and it doesn't matter
If that was the case, then just *attempting* to call fsync would corrupt
your filesystem/database- "dirty" blocks would not actually get written, but
still get marked "clean". Clearly, LVM does not interfere with writing
to the disk. It is only write barriers (waiting for the writes to
actually finish) that don't get passed through (in all but the most
simple cases). It simply returns you to the old days when the man
page for sync() said "this queues dirty blocks for writing but does not
wait for them to finish" and shutdown scripts called sync() multiple times
with sleeps in between.
> A lying fsync() doesn't blow all your mail repository up, just you may
> loose one/two messages on a crash. Or a transaction, speaking of databases.
> If that's the case, I would like to know, that's all.
Since the fsync() returns "fail" when LVM can't map it to multiple devices,
it isn't exactly "lying". And one possible response to a failure might be
to wait a bit.
According to the redhat guy, this problem came up when the simple block device
"flush" call was replaced with the more complex write barrier. LVM had
no problem passing through a simple block device flush. (Why couldn't
the simple "flush" call still be available?) I would like to know which
kernel version made this change.
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
