public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: Jan Kara <jack@suse.cz>
Cc: 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 03:50:04 -0700	[thread overview]
Message-ID: <20080125105004.GW18433@webber.adilger.int> (raw)
In-Reply-To: <20080125100545.GB10202@atrey.karlin.mff.cuni.cz>

On Jan 25, 2008  11:05 +0100, Jan Kara wrote:
> 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.

As for fsync(), we definitely need to preserve correct behaviour for the
file itself, but there isn't a requirement that ext2 behave exactly like
ext3 (it of course cannot).  In the proposed ext4-mount-unjournaled-ext2
case, the superblock would be marked dirty as it is today and an e2fsck
would need to be run at boot time.  That is fine so long as the fsync()
will cause the one file's data to be on disk before it returns.

> 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.

I don't think it is a requirement that ext3 mounting a filesystem without
a journal has to use page cache for directories.  I wouldn't object to
that being fixed.  It definitely isn't a requirement for this to work,
just an implementation difference.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

  reply	other threads:[~2008-01-25 20:24 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
2008-01-25 10:50         ` Andreas Dilger [this message]
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=20080125105004.GW18433@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=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