[Top] [All Lists]

Re: Questions about XFS

To: Stefan Ring <stefanrin@xxxxxxxxx>
Subject: Re: Questions about XFS
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 11 Jun 2013 13:03:18 -0500
Cc: Ric Wheeler <rwheeler@xxxxxxxxxx>, Steve Bergman <sbergman27@xxxxxxxxx>, Linux fs XFS <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAAxjCEwvudBHV1LAEKOabTBk7no4uXV8RbfZDbm5E=TjA_Vm5A@xxxxxxxxxxxxxx>
References: <loom.20130611T112155-970@xxxxxxxxxxxxxx> <51B72D3D.5010206@xxxxxxxxxx> <CAO9HMNGjdikgX+_434aGVJ2NAJ0hxDNLo+Vsa46GH3psXr4sKQ@xxxxxxxxxxxxxx> <51B75C39.3030306@xxxxxxxxxx> <CAAxjCEyne63XH1Uk6_7jzjaxDbsSopO9E+=6oo3xE=PvjBFcjA@xxxxxxxxxxxxxx> <51B75EF7.40801@xxxxxxxxxx> <CAAxjCEwvudBHV1LAEKOabTBk7no4uXV8RbfZDbm5E=TjA_Vm5A@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
On 6/11/13 12:41 PM, Stefan Ring wrote:
>>> Every database software will do the flushing correctly.
>> Stefan, you are making my point because every database will do the right
>> thing, it won't rely on ext3's magic every 5 second fsync :)
> Ok, let us agree on this one then ;)
> There is still kind of a dichotomy regarding the entire issue. While
> in many cases, noone will complain about a few  seconds of lost data,
> it is an entirely different beast if you lose an entire file that may
> have been added to and maintained over month/years, just because the
> system went down at an unfortunate moment. In my opinion, having a
> consistent, yet possibly somewhat outdated file, is much more
> important than having the most recent view in an inconsistent/broken
> state.

But the application needs to watch out for that too.  Appending to, or
overwriting part of a file, should never result in whole-file loss on a crash,
although it may lead to data inconsistency.  If you truncate the file and 
there is more risk.

If you want atomic updates so that you get either-old-or-new-version,
that can be accomplished.

>From the LWN article we keep linking to ;)

Similarly, if you encounter a system failure (such as power loss, ENOSPC or an 
I/O error) while overwriting a file, it can result in the loss of existing 
data. To avoid this problem, it is common practice (and advisable) to write the 
updated data to a temporary file, ensure that it is safe on stable storage, 
then rename the temporary file to the original file name (thus replacing the 
contents). This ensures an atomic update of the file, so that other readers get 
one copy of the data or another. The following steps are required to perform 
this type of update:

    create a new temp file (on the same file system!)
    write data to the temp file
    fsync() the temp file
    rename the temp file to the appropriate name
    fsync() the containing directory 


<Prev in Thread] Current Thread [Next in Thread>