Greg Freemyer wrote:
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.fsync() is a file system call that writes dirty buffers, and then waits for the physical writes to complete. It is only the waiting part that is broken.It's a yes or no question... Fsync() either guarantees that the write is committed to physical media so the application can continue knowing that it's own transactional expectations are met (i.e. you can crash and recover that piece of data), or it is broken. If it doesn't wait for completion, it can't possibly report the correct status.This discussion seems a bit bizarre to me.
You can't avoid a discussion of expected but missing functionality.
Many apps require data get to stable memory in a well defined way. Barriers is certainly one way to do that, but I don't think barriers are supported by LVM, mdraid, or drbd. Those are some very significant subsystems. I have to believe filesystems have another way to implement fsync if barriers are not supported in the stack of block susbsystems.
If you can't get the completion status from the underlying layer, how can a filesystem possibly implement it?
Maybe this discussion needs to move to a filesystem list, since it is the filesystem that is responsible for making fsync() work even in the absence of barriers.
I though linux ended up doing a sync of the entire outstanding buffered data for a partition with horrible performance, at least on ext3.
-- Les Mikesell lesmikesell gmail com