xfs
[Top] [All Lists]

Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: linux software RAID, 2.6.6, XFS, Postgres: corrupt files
From: Ian Westmacott <ianw@xxxxxxxxxxxxxx>
Date: Thu, 14 Apr 2005 16:31:41 -0400
Cc: James Foris <jforis@xxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20050414052447.GB1855@frodo>
References: <425DD4CD.1090108@xxxxxxxxx> <000401c540ad$d865d780$76d81e42@xxxxxxxxxxxxxxxxxxx> <20050414052447.GB1855@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
> > -- we are currently verifying a workaround:  we added a pseudo-service
> >    during shutdown that does
> > 
> >    dd if=/dev/zero of=/xfs_filesystem/junk bs=64k count=8k
> > 
> >    (and removes junk on startup).  On a system where this was
> >    nearly 100% repeatable, we have now gone though 10 reboot cycles
> >    without a problem (tests continue -- tough at a beta site).

verification of this workaround failed.  It is still possible to
get corruption.

> If you can, try to come up with a step-by-step test case so that
> we can reproduce your situation locally - thats a huge help.

I'm working on simple reproduction steps (without luck so far).
Our procedure involves creating a database and rebooting while
it is under load.  If I find something simple, I'll send it.

One difference in our experience from Jim's is that corruption
can occur when the filesystem is 5% full.  We have not been able
to produce a failure with his script (though we have not gotten
the filesystem up to 70% yet with that procedure).

We have noticed that some calls to xfs_unmount_wait were added to
xfs_unmount in modid xfs-linux:xfs-kern:182694a, commenting on
async buffers.  Any chance that is related (we don't have that
patch)?

Thanks,

        --Ian



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