[Top] [All Lists]

Re: vim file write mode on journaling fs.

To: Steve Lord <lord@xxxxxxx>, Bram Moolenaar <Bram@xxxxxxxxxxxxx>
Subject: Re: vim file write mode on journaling fs.
From: Seth Mos <knuffie@xxxxxxxxx>
Date: Sat, 11 Aug 2001 23:51:54 +0200
Cc: Russell Cattelan <cattelan@xxxxxxxxxxx>, Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <200108112126.f7BLQWe26468@xxxxxxxxxxxxxxxxxxxx>
References: <200108111848.f7BIm1704198@xxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
At 16:26 11-8-2001 -0500, Steve Lord wrote:

OK, just picking a message to respond to from this thread.


  4. Anyone who is shutting down their system by pulling the plug
     rather than doing an orderly shutdown is asking for trouble.
     Yes, it is a situation we want to deal with fairly gracefully,
     but filesystem recovery in journaling filesystems and fsck in
     others is there to 'recover' from problems, not to cater to
     lazy users. umount is there for a reason.

Yes, but crashes can ocur in a perfect world.

    5. With XFS it looks like this:

        o write system call comes in looks for space in the file, if
          there is none it asks the filesystem for some, the filesystem
          records the fact that space was requested at this point in the
          file. A buffer is allocated as before, it is marked dirty, it
          is also marked delayed allocate. The write returns.

        o Possibly an inode flush or a log flush pushes the new inode
          out to disk.

        o The bdflush daemon comes along and sees the buffers as being
          delayed allocate, it calls the filesystem to allocate the space.
          The allocate is done, and the buffers are written out to disk.
          The transaction which records the extents is still in memory
          and will not be flushed for a few seconds yet.

      This last sentence is the major difference, and is probably what is
      biting here, the write has not really happened until this metadata
      makes it out to disk. We may be having some issues with how long
      this is taking in Linux.

Weird, I expected the data to get written first and then the metadata. If that would happen you would have no file, or in our case, the old file.

So the upshot of all of this is that I suspect we do have an issue, and we
will get to it at some point. In the mean time there is no need to start
discarding filesystems which do not behave as you want them to do if you
pull the plug.

Hey, we have lot's of time to fix it. I could have used all those 30 minutes of time that I saved from fscking my filesystem but I used it to play Quake 3 instead.


Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.

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