public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Theodore Tso <tytso@MIT.EDU>, Eric Sandeen <sandeen@redhat.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH, RFC] Add new "development flag" to the ext4 filesystem
Date: Fri, 25 Jan 2008 11:05:45 +0100	[thread overview]
Message-ID: <20080125100545.GB10202@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20080123215029.GB18433@webber.adilger.int>

  Hi,

> On Jan 23, 2008  11:53 -0500, Theodore Tso wrote:
> > Since I'm still hoping that
> > some point in the future, fs/ext4 could subsume fs/ext3 so we don't
> > have to worry about bug fixes going into fs/ext2 AND fs/ext3 AND
> > fs/ext4, I have my own reasons for wanting that.
> 
> If any newbie kernel hacker wants a filesystem project, allowing ext4
> to mount ext2 filesystems w/o a journal would be very useful.  I
> suspect that a simple flag check in the ext4_journal_* wrappers of the
> jbd2 functions would be enough in many cases.
> 
> One of the reasons to keep ext2 around is that ext3 cannot mount the
> filesystem without a journal, and removing that limitation for ext4
> would bring us one step closer to removing a ton of duplicate code.
> Another reason for ext2 vs. ext3 was overhead from journaling, and
> that could also be removed by allowing ext4 to mount ext2 filesystems
> w/o a journal.
  Actually, folding ext2 into ext3/4 isn't as easy as one would guess in
the beginning. For example ext2 on fsync() just sync's a single inode
(and has to use private_list to track metadata buffers associated with
the inode) while ext3 flushes the whole journal. Also in ext2, directory
handling code is quite different. ext2 works in page cache of the
directory while ext3 uses page cache of the underlying device via buffer
heads - at least this second thing would be more or less mechanical
thing to change and would make sence (we wouldn't have to reimplement
readahead in ext3 directory handling code as we do now). I've looked at
it once but then more urgent things came and ... you know it.

								Honza
-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs

  reply	other threads:[~2008-01-25 10:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-22 23:17 [PATCH, RFC] Add new "development flag" to the ext4 filesystem Theodore Tso
2008-01-23  3:55 ` Eric Sandeen
2008-01-23 16:53   ` Theodore Tso
2008-01-23 17:04     ` Eric Sandeen
2008-01-23 17:26       ` Theodore Tso
2008-01-23 21:50     ` Andreas Dilger
2008-01-25 10:05       ` Jan Kara [this message]
2008-01-25 10:50         ` Andreas Dilger
2008-01-28 12:16           ` Jan Kara
2008-01-30 22:26 ` supersud501
2008-01-30 22:48   ` Theodore Tso
2008-01-30 23:03     ` supersud501

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=20080125100545.GB10202@atrey.karlin.mff.cuni.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.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