[linux-lvm] fsync() and LVM

[Marco Colombo]

[Please forgive double-posting, I'm not sure my previous attempt
succeeded]
Dietmar Maurer wrote:
>>> Does that mean I should never use more than one device if I have
>>> applications depending on fsync (databases)?
>> It just means that write barriers won't get passed to the device.
>> This is only a problem if the devices have write caches.
> 
> But fsync is implemented using 'write barriers' - so fsync does not
> work?
> 
> After fsync, all data should be sent from the OS to the disk controller:
> 
> a.) this work perfectly using LVM?
> 
> b.) this does not work at all using LVM?
> 
> c.) it works when you use one single physical drive with LVM?
> 
> I am confused. The thread on the postfix list claims that it does not
> work at
> all?

Well, it's on the PostgreSQL list, not postfix. But it may affect postfix
as well. Quoting postfix documentation:

 Gory details: the Postfix mail queue requires that (1) the file system
 can rename a file to a near-by directory without changing the file's
 inode number, and that (2) mail is safely stored after fsync() of that
 file (not its parent directory) returns successfully, even when that
 file is renamed to a near-by directory at some later point in time.

If fsync() doen't work, point (2) is not fulfilled.


Please note: that on PostgreSQL list is not speculation. It comes from
measurements. Benchmarks show too high transaction rates, just as if
fsync() was disabled. The explanation (they provided) is that LVM does
not honor fsync().


By some reading I've done I'm not sure. Is blkdev_issue_flush() we're
talking about? Please see: http://lkml.org/lkml/2007/5/25/71
Is a LVM (well, device mapper) device still a "FLUSHABLE device" by
that definition? Apparently it's ok not to support BIO_RW_BARRIER, as
long as you support blkdev_issue_flush(). Has something changed since then?

How would you classify a LVM device? SAFE, FLUSHABLE, BARRIER or
something else (UNSAFE)?

.TM.