linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Freemyer <greg.freemyer@gmail.com>
To: tytso@mit.edu
Cc: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>,
	Jan Kara <jack@suse.cz>,
	akpm@linux-foundation.org, adilger@sun.com,
	linux-ext4@vger.kernel.org
Subject: Re: [RFC] do you want jbd2 interface of ext3?
Date: Wed, 17 Feb 2010 13:09:30 -0500	[thread overview]
Message-ID: <87f94c371002171009i2a8ffe2aib43b82c1cf65104@mail.gmail.com> (raw)
In-Reply-To: <20100217164933.GC5337@thunk.org>

On Wed, Feb 17, 2010 at 11:49 AM,  <tytso@mit.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-02-17 18:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16  7:41 [RFC] do you want jbd2 interface of ext3? Toshiyuki Okajima
2010-02-16 14:31 ` tytso
2010-02-16 18:54 ` Jan Kara
2010-02-17  8:36   ` Toshiyuki Okajima
2010-02-17 16:49     ` tytso
2010-02-17 18:09       ` Greg Freemyer [this message]
2010-02-17 19:16         ` tytso
2010-02-22  5:44       ` Toshiyuki Okajima
2010-02-22 13:55         ` Theodore Tso
2010-02-22 18:02           ` Jan Kara
2010-02-22 18:57             ` Dmitry Monakhov
2010-02-26  7:25           ` Toshiyuki Okajima

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87f94c371002171009i2a8ffe2aib43b82c1cf65104@mail.gmail.com \
    --to=greg.freemyer@gmail.com \
    --cc=adilger@sun.com \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=toshi.okajima@jp.fujitsu.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).