linux-ext4 - Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?

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: <2D834B48-0EDF-4A39-B09E-8188C36D62A6@dilger.ca>
Date:	Mon, 14 Feb 2011 13:59:29 -0700
From:	Andreas Dilger <adilger.kernel@...ger.ca>
To:	Ted Ts'o <tytso@....edu>
Cc:	Amir Goldstein <amir73il@...il.com>, Jan Kara <jack@...e.cz>,
	Michael Rubin <mrubin@...gle.com>,
	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?

On 2011-02-14, at 12:58, Ted Ts'o wrote:
> On Mon, Feb 14, 2011 at 09:00:58PM +0200, Amir Goldstein wrote:
>> Yes, of course. Upgraders won't be the ones using snapshots.
>> My intension was to state that those people installing new systems to test
>> snapshots would be functioning as testers for "ext3 mode", because:
>> 1. when no snapshots exists it boils down to testing "ext3 mode".
>> 2. it is unlikely that snapshots will mask "ext3 mode" bugs.
>> 
>> So my claim is that "ext3 mode" would benefit from a transition
>> period in which snapshots and (extens,delalloc) are mutually
>> exclusive in ext4.
> 
> Here are the requirements that I think are critical before we do this:
> 
> 1) We need to solve the testing matrix problem.  Right now "ext3 mode"
> in ext4 doesn't get enough testing as it is.  Part of the solution is
> (a) deciding on the modes that need testing, and (b) writing some
> shell scripts so that xfstests can be automatically run in all of the
> right modes.  And then it will be having some number of people
> (hopefully not just me) running said tests and reporting failures.

I think the vast majority of systems use the default ext3 features as set by "mke2fs -j": "has_journal ext_attr resize_inode dir_index filetype sparse_super large_file"

> One thing that comes to mind about your question with the
> e4b->alloc_semp causing problems.  If the only reason why we need it
> is to protect against multiple attempts to initialize different block
> groups that share the same buddy bitmap, can we solve the problem by
> ditching e4b->alloc_semp entirely, and simply using lock_page() on the
> buddy bitmap page to protect it?

With flex_bg it might make sense to just read all of the bitmaps into that page in one shot, and avoid additional seeking later.  This won't consume any additional RAM, because the page is already allocated, but can give a good performance win.

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