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

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



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


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