lkml.org 
[lkml]   [2004]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: XFS: how to NOT null files on fsck?
    Date
    From
    Chris Wedgwood wrote:
    >
    > On Tue, Jul 13, 2004 at 11:34:54AM +0200, Anton Ertl wrote:
    >
    > > It would be the former owner of the block.
    >
    > there might not be a former owner (in most cases there probably isn't)

    If the owner of the file is not the former owner of the block, the FS
    certainly should not put the block in the file.

    > > So, how do you tell?
    >
    > code inspection and/or testing

    How do you test?

    Code inspection is good, but I think it needs to be complemented by
    testing.

    > > Where is data not critical?
    >
    > that depends on the person and situation, for me personally lots of my
    > data isn't critical. certainly it's annoying to loose data but
    > probably not life threatening

    We are balancing three things: making the file system nicer; working
    around non-nice file-systems in the applications; and losing data
    (even if it's just annoying rather than life-threatening). IMO losing
    data is the worst of these alternatives, and making file system nicer
    is the best one.

    > > I had such a problem even with a widely-used application like GNU
    > > Emacs (many years ago, may be fixed now), casting doubt on your
    > > claim that fixing the application is easy.
    >
    > emacs will usually rename the old file so at the very least you have
    > that

    Emacs does that only once per session, and I tend to stay in an Emacs
    session for days or weeks (and others probably do so, too). Then
    there is the auto-save file, but unfortunately eager meta-data updates
    trash that, too (see
    <http://www.complang.tuwien.ac.at/anton/sync-metadata-updates.html>).

    > > ext3 data=ordered will probably also work better in most cases than an
    > > FS with eager meta-data updates (like, apparently, XFS), but I don't
    > > think it guarantees in-order semantics.
    >
    > i thought that was the point of it? as best as i can tell the
    > metadata changes will become visible after the data has updated

    Right, but that's not sufficient. I am not an expert on ext3, but
    from the description I have read that's all it guarantees. If an
    application does a meta-data update, and then a data update, the disk
    state on crash might be that the data update was done and the
    meta-data update was not, which is not any of the states that ever
    existed logically.

    > however, in the case of something like kde/emacs/whatever you can
    > *still* loose data
    >
    > consider something like:
    >
    > open with truncate
    > crash
    >
    > or more likely:
    >
    > open with truncate
    > write some data
    > crash
    >
    > there is also an even more common case than either of these:
    >
    > open with truncate
    > write data, get -ENOSPC
    > spplication terminates/aborts
    >
    > at which point you've stomped on your file. it's non uncommong for
    > KDE to do this (even though the window would apparently be very small)

    There are certainly ways that an application can lose data even with a
    fully synchronous file system (which is the semantically nicest thing
    you can ask for (ignoring transactions)), but I am not talking about
    that. Applications can be tested against that relatively easily by
    killing the application and seeing if the files are ok.

    I am talking about ways that data can be lost because the file system
    does not have the nice semantics of a fully synchronous one. The
    in-order guarantee is something that can be implemented relatively
    efficiently and that does not add any local ways that data can be lost
    or become inconsistent (it does add ways to become inconsistent in
    distibuted applications, though, but there are fewer of these
    applications around, and their programmers are more used to thinking
    about concurrency, and thus hopefully better prepared to insert fsybcs
    etc. at the right place).

    - anton
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:2.783 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site