xfs
[Top] [All Lists]

Re: bdflush (was: corrupt inode)

To: Federico Sevilla III <jijo@xxxxxxxxxxxxxxxxxxxx>, Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
Subject: Re: bdflush (was: corrupt inode)
From: Seth Mos <knuffie@xxxxxxxxx>
Date: Thu, 09 Aug 2001 18:43:34 +0200
In-reply-to: <Pine.LNX.4.33.0108092204130.13518-100000@xxxxxxxxxxxxxxxxx ction.local>
References: <3B7296F9.E1FAB9CA@xxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
At 22:13 9-8-2001 +0800, Federico Sevilla III wrote:
On Thu, 9 Aug 2001 at 08:58, yocum@xxxxxxxx wrote:
> Nope. If the machine dies while there's still data in the buffer (in
> local memory cache) that data is gone.

And it's possible to get files filled with binary zeroes, which is
explained in the FAQ. Right?

Explanation will follow soon, a bit tied up at the moment. Tonight perhaps.

I am still unclear as to whether the actions of bdflush are equivalent to
those of sync, though, at least with XFS. (I am not sure whether this is
filesystem-specific or not)

I don't think defining it per filesystem would be efficient. I guess this goes for all filesystems

Also: let's say I modify a small file, then leave the system active for 30
seconds. Theoretically that means the data would have been flushed to disk
already, right?

It does on my system.

 Assuming write cache is turned off, of course. Then will
turning off the machine (or it dying for some reason) cause a file filled
with binary zeroes?

No, it will only do that if the program in question would actually truncate the file IIRC.

 It shouldn't, at least by my limited understanding. I
hope I am correct.

A email spool would probably not be affected since those programs are a lot more secure in making sure that the data goes to disk.

http://marc.theaimsgroup.com/?l=linux-xfs&m=99535721114156&w=4

vi -r <file>

Seems to be the right way to do it. Pico does not exhibit this problem, better yet it seems this clients calls a sync after saving and exiting. I was real fast but it got it's data to disk.
So i would say this is a "safe" editor ;-)

The journaling fs is not to blame, it does it's work correctly. The application needs to have some form of modern day filesystems. Does anybody have a ReiserFS or JFS filesystem to test this with?

I also tried this trick with vi and sure thing the file got filled with nulls. Somebody should patch vi to have a "fsync" operation mode. Otherwise you should put an alias in your .profile like:
alias vi='vi -r'

Or something resembling that.

Cheers
--
Seth
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>