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

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



On Mon, Mar 16, 2009 at 4:28 PM, Les Mikesell <lesmikesell gmail com> wrote:
> 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?

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.

>> 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.

> --
>  Les Mikesell
>   lesmikesell gmail com

Greg
-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com


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