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:	Wed, 17 Feb 2010 13:09:30 -0500
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	tytso@....edu
Cc:	Toshiyuki Okajima <toshi.okajima@...fujitsu.com>,
	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 11:49 AM,  <tytso@....edu> wrote:
> 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

Having little knowledge on my part, it sounds like it is time to open
up jdb3 for leading edge development and turn jdb2 into the new stable
platform and move jdb into legacy status.

If it really does only have one user at this time jdb is basically
just legacy at this point anyway.

Greg



-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
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