Re: XFS: how to NOT null files on fsck?

From: Anton Ertl (anton_at_mips.complang.tuwien.ac.at)
Date: 07/14/04

  • Next message: Anton Ertl: "Re: XFS: how to NOT null files on fsck?" 
    To: cw@f00f.org (Chris Wedgwood)
Date:	Wed, 14 Jul 2004 20:49:03 +0200 (CEST)

    Chris Wedgwood wrote:
    >
    > On Tue, Jul 13, 2004 at 03:33:23PM +0200, Anton Ertl wrote:
    >
    > > 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.
    >
    > sorry, i dont understand that

    I'll try to put it another way:

    If a free block was last allocated to a file belonging to user U, then
    it may be ok (it's not a security problem) to put the block in a
    file belonging to user U on recovery; if not, then it's certainly not
    ok to put it into such a file without erasing it first.

    If you don't understand that, please let me know where I am losing
    you.

    > > How do you test?
    >
    > running the code and pressing reset or similar

    Ok, I was thinking about this testing methodology, too. That's not
    what I call easy, and it has led to the current situation where many
    applications are not safe against the not-so-nice crash semantics of
    many file systems.

    > > 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.
    >
    > i don't see how for ordered updates that can occur, otherwise they
    > wouldn't be ordered

    Full-blown ordering is hard in a file system that overwrites allocated
    blocks. E.g., consider writing a little bit to block A, then writing
    something to block B, then writing something to block A again. For
    proper in-order semantics these writes have to occur in that order,
    and the first write to block A must not already include the second
    write; this becomes complicated with lazy writing. Soft Updates do
    funny things with the cache to get the ordering of operations right.

    I don't know if ext3 data=ordered does any of this, but the
    description "data updates are flushed to disk before transactions
    commit" does not sound like it does.

    OTOH, the data=ordered approach may be good enough for most
    applications (which deal with whole files rather than changes to parts
    of a file), so maybe any further effort will not provide enough
    benefit to gain much popularity. It's certainly much nicer than any
    eager-meta-data-update system like (apparently) XFS.

    > > Applications can be tested against that relatively easily by killing
    > > the application and seeing if the files are ok.
    >
    > i've seen both KDE emacs loose data by crashing, does the fix for that
    > belong in the fs too?

    Application crashing? No; I don't see how the file system can fix
    that.

    I have never seen Emacs lose data from crashing or (more frequently)
    being killed. Do you have an idea what went wrong in your case and
    how they

    In any case, if the developers have a hard time protecting even
    against application crashes/kills, I would not expect them to go to
    the effort and succeed in protecting against not-so-nice FS crash
    semantics.

    > > 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.
    >
    > mount -o sync

    Very slow, and I would not trust it, because it probably receives very
    little testing.

    > > The in-order guarantee is something that can be implemented
    > > relatively efficiently
    >
    > let's see a patch, please give details of performance differences

    Take a look at <http://www.complang.tuwien.ac.at/czezatke/lfs.html>.
    For performance results look at Section 7 of
    <http://www.complang.tuwien.ac.at/papers/czezatke%26ertl00/>. I would
    not recommend using that stuff instead of any of the established FSs,
    but it may be good enough to answer your questions.

    > what you want a much more high-level semantics in the filesystem which
    > possibly will have large performance implications.

    I don't think that the performance implications are large in typical
    situations, in crontrast to the solution you proposed (mount -o sync).

    > im not sure such
    > semantics are *required* to be in the fs or should be there

    Required by whom? Me? Yes!

    > also, this is fixing the relatively rare case where the system
    > crashes, which to be quite honest is a bigger concern, why no seek
    > solutinos that deal with more common failure modes like applications
    > crashing or bahaving badly?

    What I am proposing is extending the solutions for that to also work
    for the system crash case. This will increase the incentive for the
    programmers to fix the application crash case.

    BTW, the way my current hardware acts up, system crashes are more
    frequent than application crashes, and certainly more frequent than
    applications behaving badly.

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

  • Next message: Anton Ertl: "Re: XFS: how to NOT null files on fsck?"

    Relevant Pages

    • Re: OT: Cheney confirms that detainees were subjected to water-boarding
      ... But the USA has never stood for torturing prisoners of ANY ... Nice try at deceptive word play but it was not a 'crash' any more than ... a cruise missile 'crashes' into an enemy target. ... to force through with loud crashing noises ...
      (alt.guitar.amps)
    • Re: Problem with VB crashing
      ... I copied two of the projects (that were crashing VB) over to another ... no need to install SP-6) ... crashes VB every time. ... the other project still does NOT crash VB. ...
      (microsoft.public.vb.general.discussion)
    • Re: Well said Dean, in fact, outstanding!
      ... Only if you include the crashing part. ... you only condemn drunk driving if they actually crash or hit someone? ... make the news if now one crashes, but it is still unacceptable behavior, ... but if they run some into a bridge, then it's the 10' o'clock news. ...
      (rec.motorcycles.racing)
    • Re: View of Memory Use
      ... Not that kind of crash. ... It doesn't "cause crashing", it crashes itself. ... Any kernel panic I've had has been preceded by Safari hanging, ...
      (comp.sys.mac.advocacy)
    • Re: What to do when Word constantly crashes?
      ... crash", but I use them all day every day (I am a professional Technical ... Microsoft was one of the first to realise that being "The first to be wrong" ...  Keep the updates up to date. ...  Your crashes should stop! ...
      (microsoft.public.mac.office.word)