Re: XFS filesystem corruption

From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: Julien FERRERO <jferrero06@gmail.com>,
	Ric Wheeler <rwheeler@redhat.com>,
	xfs@oss.sgi.com
Subject: Re: XFS filesystem corruption
Date: Sat, 9 Mar 2013 20:11:52 +1100	[thread overview]
Message-ID: <20130309091152.GH23616@dastard> (raw)
In-Reply-To: <513A350A.508@hardwarefreak.com>

On Fri, Mar 08, 2013 at 12:59:22PM -0600, Stan Hoeppner wrote:
> On 3/8/2013 6:20 AM, Ric Wheeler wrote:
> > On 03/08/2013 03:39 AM, Stan Hoeppner wrote:
> >> On 3/6/2013 5:12 PM, Ric Wheeler wrote:
> >>
> >>> We actually test brutal "Power off" for xfs, ext4 and other file
> >>> systems. If your storage is configured properly and you have barriers
> >>> enabled, they all pass without corruption.
> 
> I think you missed the context.  Please reread this:
> 
> >> Something that none of us mentioned WRT write barriers is that while the
> >> filesystem structure may avoid corruption when the power is cut, files
> >> may still be corrupted, in conditions such as any/all of these:
> 
> I made it very clear I was discussing file corruption here, not
> filesystem corruption.  You already covered that base.  I was
> specifically addressing the fact that XFS performs barriers on metadata
> writes but not file data writes.

Actually, you're not correct there, either, Stan. ;)

XFS only issues cache flushes/FUA writes for log IO. Metadata IO is
done exactly the same way that data IO is done - without barriers.
It's because metadata lost in drive caches at the time of a crash is
rewritten by journal replay that filesystem corruption does not
occur.

As it is, if the application uses direct IO (likely, as it
sounds like video capture/editing/playout here) then log IO
will also ensure that the data written by the app is on disk (i.e.
that's ithe mechanism by which fsync works).

Hence even assumptions that there will be data loss are dependent on
how the application is doing it's IO....

> > Also, if there are active writers, this is inherently racy. A better
> > script would unmount the file systems :)
> 
> Yes, a umount would be even better.

Change the bios so that the power button does not cause a power down
so the OS can capture the button event and trigger an orderly
shutdown. Laptops use power button events for all sorts of different
things (e.g. suspend rather than shutdown) and you can do exactly
the same sort of event triggered shutdown for any server or
desktop...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs