Greg Freemyer wrote:
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?
Barriers is a specific technology and they were just implemented in
linux around 2005 I think. (see documentation/barriers.txt)
Surely there was a mechanism in place before that.
I'm not sure that's a reasonable assumption.
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.
Yes, I understand fsync is horribly slow in ext3 and that may be the
reason. Supposedly much better in ext4. Still if a userspace app
calls fsync and in turn the filesystem does something really slow due
to the lack of barriers, then this conversation should be about the
poor performance of fsync() when using lvm (or mdraid, or drdb), not
the total lack of fsync() support.
I haven't seen anyone claim yet that there is support for fsync(), which
must return the status of the completion of the operation to the
application. If it does, then the discussion could turn to performance.
--
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/
