linux-kernel - Re: [RFC] fiemap tester

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 11 May 2009 12:46:15 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Theodore Tso <tytso@....edu>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Josef Bacik <josef@...hat.com>, linux-fsdevel@...r.kernel.org,
	sandeen@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC] fiemap tester

Theodore Tso wrote:
> On Mon, May 11, 2009 at 05:46:39AM -0400, Christoph Hellwig wrote:
>> Last time I brought the idea of a small in-tree test harness up at KS
>> people weren't too fond of it, but if we get more backing now we could
>> try it, otherwise we can just stick it into xfsqa which will hopefully
>> soon be generalized to a general fs QA suite.
> 
> Two questions --- first of all, has there been any progress with
> respect to fixing the licensing of the xfsqa tree.  (i.e., "All Rights
> Reserved" needs to change to a GPLv2 license)?  

We've had a verbal ack from sgi that it should be under an open-source
license.  But until that is committed to the repo....

> And would you be open to cleaning up xfsqa by for example, moving some
> of the tests out of the top-level directory, adding a modified xfs_io
> to xfsqa (modified to not avoid using XFS-specific ioctl whereever
> possible), etc.

Sure.  xfs_io already can act on non-xfs filesystems, although right now
it takes a flag to do so.  But it can do many ops* that way, and we're
open to add more (I just sent a patch to add fallocate yesterday).

As for directory layout, whatever works is likely fine.

> I've been collecting my own set of test programs for ext4, and I've
> thought about trying to use xfsqa, but it's not obvious to me it would
> be more or less work, since in many ways there are a lot of places
> where a lot of cleanup work and filesystem portability work would be
> needed, and it's not clear that creating a new test framework and
> collection of tests would be more or less work.

Yes, xfsqa would/will take some work to get there I guess.  OTOH so much
of filesystem testing could be shared, it's a shame to duplicate it for
each filesytem, too.

> (For example, of cleanup that I'd love to see, I'd really like to use
> real names for tests and not just random three digit numbers like 107,
> 108, 109, all cluterring the top-level directory along with 107.out,
> 108.out, 109.out, etc.)

Well they're not random, they are sequential ;)

But yeah at least giving each test a description (at least a
DESCRIPTION="tests fubarbaz") would be helpful.

> Of course, until the copyright/licensing situation is cleared up, all
> of these other issues are rather moot....

I'll press SGI on this...

-Eric

> 					- Ted

*fadvise, file, print, freeze, thaw, fsync, fdatasync, getrusage,
madvise, mincore, mmap, mread, msync, munmap, mwrite, open, stat, close,
setfl, statfs, pread, pwrite, sendfile, truncate
--
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/