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

[Les Mikesell <lesmikesell@gmail.com>]

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