xfs
[Top] [All Lists]

Re: Might have found a bug...

To: Tim Clymo <tim_clymo@xxxxxxxxxxx>
Subject: Re: Might have found a bug...
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Tue, 15 May 2001 17:05:47 -0400
Cc: linux-xfs@xxxxxxxxxxx
References: <F197fyQgeDKvPEkGhAj00008076@hotmail.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Tim Clymo wrote:

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

If you followed the thread and my last explanation you will note that the file
was not full of garbage but NULL's. the file had no extents  which means it
consisted
entirely of a whole aka NULL's
As to why the contents of the file where not the 'old' data, most editors
either
mv the old copy to a backup name or truncate the file before writing to it.
Effectively we are dealing with a "new" file and not one that is being
"updated" or
written over.


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

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




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