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