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: <20100217164933.GC5337@thunk.org>
Date:	Wed, 17 Feb 2010 11:49:33 -0500
From:	tytso@....edu
To:	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>
Cc:	Jan Kara <jack@...e.cz>, akpm@...ux-foundation.org,
	adilger@....com, linux-ext4@...r.kernel.org
Subject: Re: [RFC] do you want jbd2 interface of ext3?

On Wed, Feb 17, 2010 at 05:36:00PM +0900, Toshiyuki Okajima wrote:
> 
> The reason that I wanted to change the journaling interface into jbd2 were:
> - the most of my customers use linux for Mission Critical (M.C.).
> - M.C. users want the filesystems which have more integrity for their data.
> - I think we should not recommend ext4 to M.C. users because
>   for M.C. users, ext4 is still unstable filesystem.
>   Therefore I want to let M.C. users use ext3 for the present.
> - it is not easy to maintain both jbd and jbd2, so
>   I thought it was easy to solve it by unifying the journaling interfaces
>   into ext4.

But if they are mission critical users, why would they be willing to
accept changes to the jbd2 layer, and the necessary changes to ext3 so
it can use jbd2?  Any time you add changes, you will be causing a
certain amount of instability and risk.  So the question is, what are
your users willing to tolerate?

Some important questions to ask:

1) Is the problem psychological?  i.e., is the problem that it is
*called* ext4?  After all, ext4 is derived from ext3, so if they are
willing to accept new features backported into ext3 (i.e., journal
checksums) and the risks associated with making changes to add new
features, why are they not willing to accept ext4?

2) If it is a question of risk, how many changes are they willing to
accept?  I will note that if you don't enable extents, and disable
delayed allocation, you can significantly decrease the risk of using
ext4.  (Essentially at that point the only major change is the block
allocation code and the changes to use jbd2.)

3) How much testing do you need to do before it would be considered
acceptable for your Mission Critical users?  Or is it a matter of time
to allow other users to be the "guinea pigs"?  :-)

> OK. I see.
> (ext3 is already stable filesystem, so, we should not change
>  ext3 drastically.)

Well, certainly, *any* change is going to risk destablizing the file
system.  Isn't that the argument why you are concerned about whether
ext4 is ready for your M.C. users?  One of the reasons why we forked
jbd2 from jbd was precisely because of these sorts of concerned.  So
if you switch ext3 to use jbd2, would that not increase the risk to
your M.C. users?

Best regards,

      		       	      	  	    - 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