At the risk of pushing the point here...
I understand all that has been said about delayed writes, caches etc.
However, with regard to the original question in this thread, is it
still "expected behaviour" for the original source file to be full of
garbage if the system is powered off shortly after a non-synced write?
Editing a plain text file for example with vi, saving the file and
doing an immediate reset - I could understand if the file was back to
its original state before the edit was "written", but my experience is
that instead it is useless junk.
Thanks
Tim
I am going to attempt to explain a little of how XFS writes data to disk,
and what this means when the power is turned off.
For most transactions, the modifications to the filesystem are committed
to a group of in memory buffers. These buffers are flushed to disk by:
o a synchronous transaction
o being filled
o background sync activity
File data is flushed to disk via bdflush unless you use fsync, O_SYNC on
open or fdatasync.
Filesystem design is mostly about compromises between speed of operation
and safety of operation, even in the case of XFS. If you want a filesystem
which is truly safe from power outages then you have to use applications
which do I/O in a manner which indicates they want the data on disk before
the system call returns, and in the case of XFS, mount with the wsync
option which makes all transactions safe on disk before system calls
return. Of course, performance will suffer. There is a range of medical
image scanners which actually have an Irix box embedded in them using XFS.
These boxes regularly just get unplugged or have the power removed for
some reason, and the manufacturer insisted on complete data recovery
after a crash. The above factors were what got them to this state.
So if you write to a file and then immediately drop the power, the chances
are you will not see the data after reboot. If you do a metadata operation
and imediately drop power, there is also a chance it will be not be present
after reboot. The filesystem however, will be in a consistent state.
Is there anyway to mount with less latency on the writes?
You can control the frequency of data getting flushed to disk (both file
data and metadata in the journal) with the bdflush parameters in
/proc/sys/vm/bdflush
Steve
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@xxxxxxxxxxxxxxx
On Fri, 11 May 2001, Marc Jauvin wrote:
> I understand, but the file should have been kept to its original state,
no?>> I
> had garbage all over the file after the reset...
>
>
> Russell Cattelan wrote:
>
> > Marc Jauvin wrote:
>
> >> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
> >>
> >> ----
> >>
> >> I installed XFS 1.0 for RedHat 7.1 and everything is great... until
I di>> d the
> >> following:
> >>
> >> make modification to /etc/fstab, and IMMEDIATELY after saving the
> >> modifications, I hit the reset button; when the system reboots, the
> >> /etc/fstab is baddly corrupted and XFS does not fix it (end up using
the>> > >> linux rescue disk to fix fstab manually\)
> >>
> >> I could reproduce the bug 2 times;
>
> >> Any idea\?
>
> > Yes don't do that.
> > XFS uses delayed allocation / delayed write by default any data
written
> > immediacy before a crash probably won't be on
> > disk, this is known behavior and isn't considered a bug, it's a trade
off>> .
> > Full sync mode on file systems is much safer and gives more likely
hood o>> f
> > data integrity. caches gives much better
> > performance but has the potential of losing cached data in the event
of a>> > > crash.
>
>
>
> --
> marc.
>
> 3 out of 4 Americans make up 75% of the population.
>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
|