Charles Marcus wrote: > On 3/14/2009 8:51 PM, Marco Colombo wrote: >> Stuart D. Gathman wrote: >>> On Sat, 14 Mar 2009, Dietmar Maurer wrote: >>> It just means that write barriers won't get passed to the device. >>> This is only a problem if the devices have write caches. Note >>> that with multiple devices, even a FIFO write cache could cause >>> reordering between devices (one device could finish faster than another). > >> 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 the disks have write caches enabled or not. Or if they have battery backed >> caches. Please read the thread I linked. If what they say it's true, >> you can't use LVM for anything that needs fsync(), including mail queues >> (sendmail), mail storage (imapd), as such. So I'd really like to know. > > Seeing as my /var (with both postfix & courier-imap using it for mail > storage) has been on lvm for almost 4 years, that would be news to me... > > ;) > Believe me or not, they both depend on fsync(). Anyway, even if you lost a message, how do you expect to know? If you have any user base large enough, you're used to 'missing' messages (99% of the user-deleted or user-never-sent kind). A truly lost one may have gone missed in the noise. 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. .TM. _______________________________________________ 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/
