[Top] [All Lists]

Re: XFS performance issue solved

To: Federico Sevilla III <jijo@xxxxxxxxxxxxxxx>
Subject: Re: XFS performance issue solved
From: Steve Lord <lord@xxxxxxx>
Date: Mon, 14 May 2001 21:56:41 -0500
Cc: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: Message from Federico Sevilla III <jijo@i-manila.com.ph> of "Tue, 15 May 2001 09:52:15 +0800." <Pine.LNX.4.21.0105150948440.434-100000@kalapati.jijo.local>
Sender: owner-linux-xfs@xxxxxxxxxxx
> On Tue, 15 May 2001 at 08:30, Juha Saarinen wrote:
> > You might want to experiment with the -a(n), -A1, -W1 flags too. Just
> > plain -c1 is probably a tiny bit quicker than -c3 (but it might not
> > work with your chip set).
> hdparm's -W1 flag turns on the hard drive's write-cacheing, which speeds
> things up, but makes unclean power downs more dangerous. Does anyone know
> how XFS will handle such an event? While on the ReiserFS mailing list
> awhile back, I was under the impression that this could do wonderful
> damage to the filesystem, although I don't know how things are now. But
> then XFS seems to be infinitely more stable than ReiserFS, and the on-disk
> format is much more mature, so maybe (I hope) it handles things
> differently.

If write caching is enabled on drives under XFS then this could
definitely cause problems should the cache not make it out to disk.

XFS and other journalling filesystems tend to rely on write ordering
constraints to maintain consistancy. So we write metadata into the
journal and only once we know the data is on disk in the journal
do we allow the actual metadata out to disk, we do not impose any
constraints on the ordering of writes of the actual metadata.

So say we allocate a new file and place it in a directory. This
involves modifying the data structures which contain free inodes,
the directory blocks, and the inode itself. Plus possibly other
data structures if we need to allocate space for any of this.

If we write all this to the log and the disk system reports it is
on disk, we allow the metadata to go out to disk. Say the directory
blocks make it out to disk, then we crash. If the drive had write
caching on, and had decided in its infinite wisdom to keep the log
in cache, but to flush through the directory write because that is
where the disk head happened to be, we have a corrupt filesystem.

Now if you are happy that you have a disk system which can get all
the data out to disk on power failure then use write caching. But
remember that most modern drives were designed for an operating
system which when coming up from a crash or power problem gives
you the message 'Your filesystems did not appear to have been
cleanly shutdown, next time please shutdown your computer before
turning it off'.


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