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: <946A4527-3A1C-4EC5-BEAC-4E47F3CFDF01@dilger.ca>
Date:	Mon, 7 Feb 2011 08:35:31 -0800
From:	Andreas Dilger <adilger@...ger.ca>
To:	Jan Kara <jack@...e.cz>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	ext4 List <linux-ext4@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?

On 2011-02-07, at 08:19, Jan Kara wrote:
> On Fri 04-02-11 10:36:21, Andreas Dilger wrote:
>> 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.
> 
>  Well written apps do, but badly written apps don't and e.g. our distro
> customers don't always have the choice of the application. So as a developer
> I see your point (screw stupidly written apps) but in the real world, I'm
> afraid it's too hard on users.

We have to remember that this is only for new kernels, and does not affect older kernels or existing applications, so such users shouldn't be affected.

>> 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?
> 
>  Yes, I know you are on relatively radical side ;). My position would be
> to test ext4 for resonable combinations of options as ext2 driver and if
> that works, switch ext2 as you describe. Then if it works fine for an year
> or so, we can talk about ext3 but as James said, ext3 is still widely used
> so there might be more friction on subtle runtime differences...

Since most new distros use ext4 by default, the point is kind of moot, because those users will get this behaviour in any case.  Relatively few users upgrade their kernel on a production system after it is installed, except for errata kernels, and I definitely wouldn't expect such a change to appear in an errata kernel.

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