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]

Date:	Fri, 4 Feb 2011 10:36:21 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Jan Kara <jack@...e.cz>
Cc:	Eric Sandeen <sandeen@...hat.com>, Jan Kara <jack@...e.cz>,
	"lsf-pc@...ts.linuxfoundation.org" <lsf-pc@...ts.linuxfoundation.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?

On 2011-02-04, at 6:03, Jan Kara <jack@...e.cz> wrote:
>> I think that ext4 with nodelalloc should mostly mimic ext3 in those
>> cases, no?
>  Yeah, mostly. The biggest obstacle I see here is the different behavior
> of mmap - with nodelalloc allocation happens at the time of page fault and
> that fragments the file like hell for some kinds of load. Since ext3 here
> essentially does delayed allocation, it might be useful to do delayed
> allocation only from page fault path when we try to mimic ext3 behavior.
> So mimicking ext3 is possible but needs some tweaks...

The question is whether we need to mimic the runtime behavior or just the on-disk format?  Apps already need to deal with ext4 and other fs that do not do ext3 ordered mode. 

>> If we can have a real plan for moving in this direction though, I'd
>> support it.  I'm just not sure how we get enough real testing under
>> our belts to be comfortable with dropping ext[23], especially as
>> most distros now default to ext4 anyway.
>  Well, I believe this actually works for us. If the real users move to
> ext4 (or a different fs), then it's easier to make ext[23] mode in ext4
> good enough for the few legacy users...

I think the best road forward is to make ext4 the default for ext2 and ext3 filesystems in newer kernels, and mark ext2 and ext3 obsolete. This will start to get usage and testing of these other config options. The ext2 mode is already heavily tested at Google, and don't they also test noextent mode on updated filesystems, or were all of the filesystems reformatted with ext4 options?

After some number of kernel releases with ext4 as the default, we could remove the ext2 and ext3 code. 

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