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: <20140502140407.GB842@thunk.org>
Date:	Fri, 2 May 2014 10:04:07 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Lukáš Czerner <lczerner@...hat.com>
Cc:	"Darrick J. Wong" <darrick.wong@...cle.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 37/37] ext5: define new subtype to add features and
 reduce testing complexity

On Fri, May 02, 2014 at 11:45:25AM +0200, Lukáš Czerner wrote:
> This is definitely NACK by me. I do not like this and there are
> several reasons why.
> 
> First of all the name. Given the history of ext file system we tend
> to increase then number with the new version of file system. However
> you're saying that this is just for testing features ... in that
> case it does not make any sense to call it ext5, but not just that
> it's stupid to call it ext5 especially since we might actually want
> to release ext5 in the future and this would be really confusing for
> everybody involved.

Yes, the messaging involved with the "ext3" vs "ext4" bump has been
really unfortunate.  If I had to do it all over again, I would have
created "ext3dev", and then when it was stable, I would done a:

	git rm -rf fs/ext3 ; git mv fs/ext3dev fs/ext4

For example, it would have avoided the problem with SuSE product
managers refusing to support ext4 for multiple years, etc.

It also would have avoided the problem with people doing comparisons
of ext3 versus xfs, even in April 2014 (see a recent Hacker News
promoted blog article, where in someone kvetched that ext3 didn't
support fallocate).  Sigh....

> What about just simply using mkefs.conf to specify the feature set
> we want and use that?

Yes, it's likely that for 1.43 we'll enable various features by
default.  It's been quite deliberate that I haven't enabled by
default, because I wanted to make 100% sure they were completely
stable before enabling them by default.  Some of them we may have been
able to enable by default earlier, but be that as it may, 1.43 is a
good time to make that change.

				- 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ