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]
Date:	Thu, 2 Jun 2011 11:22:53 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	"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 2011-06-02, at 8:59 AM, Eric Sandeen wrote:
> On 6/2/11 2:16 AM, Amir G. wrote:
>> OK, after upgrading to newer util-linux and building it from git,
>> which also didn't help, I finally found who to blame - me.
>> I had an old (noauto) entry in /etc/fstab which claimed that /dev/sda5 is ext4.
>> fsck was picking up that entry and insisting that /dev/sda5 is ext4
>> (regardless of what it really is)
>> blkid isn't doing that silly thing.
> 
> So where are we at with all this?
> 
> 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.

> But other than that, I don't think we should be making changes to upstream projects based on your current development hacks (I don't mean hack in a bad way, just that running sed across ext4 to create your custom filesystem for testing should not require upstream projects to change...)

No, but it's not like this is affecting a lot of tools, just one that is
used by filesystem developers.

> So I'm ok with sprinkling "ext4|ext4dev" around if necessary.  Anyone else disagree?

The other alternative is to change all of the "ext2|ext3|ext4|ext4dev" case
statements to be "ext[2-9]*", or "ext[3-9]*", or "ext[4-9]*" for checks that
are only valid for newer codes and be done with it.  It's a lot easier to
read, and we don't have to change it again should we ever get ext5 or whatever
(hopefully btrfs will be ready before that, but who knows).

Cheers, Andreas





--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ