linux-kernel - Re: reiserfs broken in 2.6.32 was Re: [GIT PULL] reiserfs fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100103032758.GP828@thunk.org>
Date:	Sat, 2 Jan 2010 22:27:58 -0500
From:	tytso@....edu
To:	Christian Kujau <lists@...dbynature.de>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexander Beregalov <a.beregalov@...il.com>,
	Chris Mason <chris.mason@...cle.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: reiserfs broken in 2.6.32 was Re: [GIT PULL] reiserfs fixes

On Sat, Jan 02, 2010 at 06:05:13PM -0800, Christian Kujau wrote:
> On Sun, 3 Jan 2010 at 02:52, Frederic Weisbecker wrote:
> > [: 53: ==: unexpected operator
> > common.rc: Error: $TEST_DEV (/dev/sda3) is not a MOUNTED xfs filesystem
> 
> Yeah, I'm playing around with xfstests as well, but apparently they're 
> assuming !/bin/sh will be run under /bin/bash, which is not always the 
> case. A short fix is to link /bin/sh to /bin/bash, but perhaps some of the 
> tests can be tweaked to run under /bin/sh as well.
> 
> > I'm not sure how I can run these tests on a non-xfs partitions.
> > I must be missing something.
> 
> I haven't found an easy way to do this yet without rewriting a few 
> routines (mkfs, mount, etc...). As Ted is already using xfstests for 
> btrfs, ext4, maybe he wants to share his magic? :-)

I'm using it for ext4.  It looks like someone has already tried using
the xfstests with reiserfs; take a look at common.rc; you'll see case
statements for xfs, udf, nfs, ext2/3/4, reiserfs, and gfs2.  Someone
who wants to use xfstests for some other file system may need to
further edit common.rc.  I thought the btrfs folks were using it as
well, but at least the kernel.org git tree for xfstests doesn't seem
to show any btrfs references in common.rc, so perhaps I'm wrong about
btrfs developers using xfstests (or they haven't sent their patches
back upstream).  I'm not sure how well tested the reiserfs support is,
so you may need to edit common.rc as necessary.

In any case, the README file has pretty much what you need.  I
personally run my test kernels using KVM, and I have a run-test script
which invokes check as follows:

#!/bin/sh
export TEST_DEV=/dev/sdb
export TEST_DIR=/test
export SCRATCH_DEV=/dev/sdc1
export SCRATCH_MNT=/scratch
export EXT_MOUNT_OPTIONS="-o block_validity"
exec ./check -ext4 $*

/dev/sdb is an ext4-formated filesystem, which you're supposed to not
reformat from run to run, so that some testing can be done with an
"aged" file system.  The scratch filesystem will be reformatted for
various tests, so you shouldn't keep anything valueable on it.

I also have a 1k block file system on /dev/sdd, so I invoke check as
follows to check to make sure things work when blocksize != pagesize:

#!/bin/sh
export TEST_DEV=/dev/sdd
export TEST_DIR=/test-1k
export SCRATCH_DEV=/dev/sdc1
export SCRATCH_MNT=/scratch
export MKFS_OPTIONS="-b 1024"
exec ./check -ext4 $*

As far as the inconsistency between TEST_DIR versus SCRATCH_MNT ---
all I can say is, the XFS engineers who threw together the xfstests
scripts may have been very good file system engineers, but they
obviously weren't very well used as UI/User Experience designers.  :-)
(The documentation isn't all that great either, but patches sent to
xfs@....sgi.com do tend to be accepted and merged into the kernel.org
tree if they are clean.)

Hope this helps,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/