From: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
To: Jan Kara <jack@suse.cz>, tytso@mit.edu
Cc: 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 17:36:00 +0900 [thread overview]
Message-ID: <4B7BAA70.9070605@jp.fujitsu.com> (raw)
In-Reply-To: <20100216185452.GE3153@quack.suse.cz>
Hi, Ted and Jan!
tytso@mit.edu wrote:
> On Tue, Feb 16, 2010 at 04:41:23PM +0900, Toshiyuki Okajima wrote:
> > >
> > > jbd2 has new features from jbd. For example, it includes the
> > > integrity improvement features. The body of ext3 is already enough
> > > quality. If ext3 changes the journaling interface from jbd into
> > > jbd2, ext3 filesystem with jbd2 interface may get better integrity
> > > than with the jbd interface. (jbd2 is aggressively being developed
> > > now, so I think we are glad if we can get the effect of the
> > > development of jbd2 for ext3.)
> > >
> > > And ext3 is as de facto standard filesystem, so jbd2 component will
> > > be used by more people than now if ext3 has the jbd2 interface. If
> > > many people used the jbd2 interface of ext3, the jbd2 component
> > > would get more chances to improve the quality and performance and so
> > > on.
>
> Jbd2 is development attention because it is part of ext4. And you
> don't get to use the data integrity features of jbd2 without
OK. I understand.
(jbd2 is now developing.)
> backporting required changes from ext4 to ext3. At which point, why
> not have people use ext4?
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.
>
> Ext4 is format compatible with ext3, and with the proper kernel
> configuration options, starting with 2.6.33, it's possible to
> seemlessly allow people who use "mount -t ext3 /dev/sda1 /u1" to have
> /dev/sda1 mounted using the ext4 file system driver. So we even have
> a way that we can seemlessly upgrade existing userspace setups to
> using ext4 without having to make any system configuration changes
> (except installing a new kernel, of course).
I know this feature.
But I wanted not to let M.C. users use it now because this feature is
based on ext4.
>
> The whole point of creating the ext3/ext4 fork was to not disturb ext3
> users while ext4 was under development. This was done by effectively
> putting ext3 into a bug-fix-only development mode. Changing ext3 so
> it could use jbd2 would seem to violate the stability process that we
> have made to the ext3 users; if people want new features and
> performance improvements, they can use ext4.
Jan Kara wrote:
> Hello,
>
> On Tue 16-02-10 16:41:23, Toshiyuki Okajima wrote:
> > > I will try to change the journaling interface of ext3 from jbd into jbd2.
> > >
> > > jbd2 has new features from jbd. For example, it includes the integrity
> > > improvement features. The body of ext3 is already enough quality. If ext3
> > > changes the journaling interface from jbd into jbd2, ext3 filesystem with jbd2
> > > interface may get better integrity than with the jbd interface.
> > > (jbd2 is aggressively being developed now, so I think we are glad if we can
> > > get the effect of the development of jbd2 for ext3.)
> > >
> > > And ext3 is as de facto standard filesystem, so jbd2 component will be used
> > > by more people than now if ext3 has the jbd2 interface. If many people used
> > > the jbd2 interface of ext3, the jbd2 component would get more chances to
> > > improve the quality and performance and so on.
> > >
> > > Besides, ext3 is now the only user of jbd.
> > > (ocfs2 which was the user of jbd is now the user of jbd2.)
> > >
> > > Do you want the jbd2 interface of ext3?
> > > If you want the jbd2 interface, I will try to implement one.
> Yes, as Ted pointed out, the main reason why we have a separate codebase for
> ext3 and ext4 and similarly jbd and jbd2 is that we didn't want the changes
> in ext4/jbd2 to influence (and possibly destabilize) ext3 filesystem. So
> switching ext3 to jbd2 would be directly against this logic...
OK. I see.
(ext3 is already stable filesystem, so, we should not change
ext3 drastically.)
Thanks,
Toshiyuki Okajima
next prev parent reply other threads:[~2010-02-17 8:36 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 [this message]
2010-02-17 16:49 ` tytso
2010-02-17 18:09 ` Greg Freemyer
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=4B7BAA70.9070605@jp.fujitsu.com \
--to=toshi.okajima@jp.fujitsu.com \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.