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?
Everything will seem to work until you have an inconvenient crash or
disk error. That is, data will be written normally - whether you fsync
or not. The point of fsync() though, is for an application to confirm
that the file is committed to stable media and will be recoverable even
if the application (or OS) crashes or the system loses power. The
correct next action of the application will depend on the return status
of the fsync() operation (e.g., acknowledging receipt of a mail message,
considering a database change to be committed, etc.). What I believe
is happening is that fsync() always returns as though it were successful
even though the underlying operations haven't completed. That's
ummm..., optimistic at best. But, everything will still work (and more
quickly) as long as the physical write of the file and associated
directory metadata eventually succeeds. Realistically, for most things
it doesn't matter because for critical data you still have to deal with
the possibility of a disk write that succeeds being unreadable later for
a variety of reasons - and the rest isn't critical anyway. However, it
would be good to know exactly what to expect here.
--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
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/
