linux-ext4 - Re: [PATCH v2] xfstests: add support for ext4dev FSTYP

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: <20110603003610.GD16306@thunk.org>
Date:	Thu, 2 Jun 2011 20:36:10 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	"Amir G." <amir73il@...rs.sourceforge.net>,
	Dave Chinner <david@...morbit.com>, xfs@....sgi.com,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	sergey57@...il.com, Amir Goldstein <amir73il@...rs.sf.net>
Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP

On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote:
> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
> > I don't really mind adding ext4dev to FSTYP case statements, it
> > -is- something which blkid could, in theory, still return, and
> > making xfstests cope with that and try to invoke fsck -t ext4dev
> > doesn't bother me too much.  It is sadly an fs type embedded into
> > a few tools.
> 
> I'm perfectly OK with using ext4dev as a filesystem type that allows testing
> changes to ext4 on a system that is already running ext4 as the root fs.

My take on this is that way too much time has been spent this subject.
Being able to use ext4dev is useful, and given that we have all of
this support in our existing system tools, why not use it to make ext4
development more efficient/easy?  As a bonus you can build the ext4dev
as a module, and that means you the compile/edit/debug cycle can be
much faster since you can avoid doing a reboot, for those
circumstances where using KVM is not possible/convenient.  Personally,
I normally use KVM these days, but I can imagine situations where
using ext4dev would be a better way to go.  For example, I'd probably
use KVM on my laptop, but for testing on production servers in a data
center, I'd probably use ext4dev, for a variety of local deployment
considerations that's not worth going into here.

That being said, whether or not we modify xfstests seems to be a moot
point.  In order for me to do my bigalloc development, I've been
patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and
"/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP".  It's a 3 line change.  Not
a big deal.  I've been making this change using /bin/ed after
installing xfstests.  So if the XFS folks want to veto this change ---
who cares?  It's not hard to make the change locally in order to make
xfstests.

On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't
see why it's so important that it clings to "fsck -t $FSTYP" instead
of using "fsck.$FSTYP".  There's no real benefit to calling the fsck
driver; it's just an extra fork and exec, and xfstests is being
inconsistent by insisting on the use of the fsck driver, but not using
the mkfs driver.

But that being said, hacking xfstests is not hard, and if Dave and/or
Eric feels strongly about resisting this change, it's not worth a lot
of time, one way or another....

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