xfs
[Top] [All Lists]

Re: Testing XFS+RAID5

To: Andrew Klaassen <ak@xxxxxxx>
Subject: Re: Testing XFS+RAID5
From: Andi Kleen <ak@xxxxxxx>
Date: Mon, 18 Jun 2001 20:44:14 +0200
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20010618143236.E2209@key.dkp.com>; from ak@dkp.com on Mon, Jun 18, 2001 at 02:32:36PM -0400
References: <20010618141420.D2209@key.dkp.com> <20010618143236.E2209@key.dkp.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Mon, Jun 18, 2001 at 02:32:36PM -0400, Andrew Klaassen wrote:
> On Mon, Jun 18, 2001 at 02:14:20PM -0400, 
> Andrew Klaassen wrote:
> 
> > Anyone have any suggestions for tools to stress the system? 
> > To look for XFS+NFS and XFS+Samba bottlenecks and bugs?  To
> > make the drives fail as soon as possible, if they're so
> > inclined?
> 
> Oh - and there's one more thing I want to test for: data
> corruption.  Anybody know of any test suites out there that will
> do comprehensive tests looking for corruption?

One interesting test is that the file system is recoverable from 
a crash at all times. 

You can simulate the crash case by running it on LVM and taking LVM snapshots
periodically while doing heavy load testing. Then try to mount the snapshot
and check if it contains any damages. One problem with that is that XFS
refuses to mount a copy of an already mounted file system currently; to work
around that you need to set a different file system UUID using xfs_db before
mounting to force the mount. Then check if it is readable and if there is
any damage.

This only checks for software problems of course. For example when your
disk does use write caching or not honour flush requests or does other things
that violate write ordering assumptions you would need to actually take 
the power away to test for such problems.

-Andi

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