[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] fsync() and LVM

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]