linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "Lukáš Czerner" <lczerner@redhat.com>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: fix overhead calculation in bigalloc filesystem (Re: ... )
Date: Fri, 22 Feb 2013 10:20:42 -0500	[thread overview]
Message-ID: <20130222152042.GA19264@thunk.org> (raw)
In-Reply-To: <20130222131811.GA22069@gmail.com>

On Fri, Feb 22, 2013 at 09:18:12PM +0800, Zheng Liu wrote:
> > If there was a mode that I'd be tempted to get rid of, it would be the
> > combined data=ordered/data=writeback modes.  The main reason why we
> > keep it is because of a concern of buggy applications that depend on
> > the implied fsync() of data=ordered mode at each commit.  However,
> > ext4 has been around for long enough that I think most of the buggy
> > applications have been fixed by now.  And of course, those buggy
> > applications will lose in the same way when they are using btrfs and
> > xfs.  Something to consider....
> 
> IMHO, the application shouldn't depend on a kernel feature.  So maybe it
> is time to highlight this buggy usage.

Oh, agreed.  The question is how many people want us to keep the ext3
semantics to support those buggy applications.  To the extent that
distros are considering using ext4 to support ext3 file systems, there
might be a desire to maintain (as closely as possible) ext3 semantics,
even those that support buggy applications.  The primary problem is
that the when comes down to application developers versus file system
developers, the application developers vastly outnumber us.   :-)

> Just one minor comment below.  Otherwise the patch looks good to me, and
> it can pass in xfstests with 'data=ordered' and 'data=writeback'.

I hadn't bothered testing it yet because I'm focused on testing
and cleaning up the set of patches for the merge window --- and this
change is clearly for the next merge window.  Thanks for testing it!

> >  	trace_ext4_ordered_write_end(inode, pos, len, copied);
> 
> Here this function needs to be renamed with trace_ext4_write_end().

Yes, agreed.

I also need to get rid of trace_ext4_writeback_write_end() in
include/trace/events/ext4.h.

The other thing that needs to be done --- probably in a separate
commit, just to make things easier to review for correctness, is now
that we've folded ext4_writeback_write_end() and ext4_ordered_write_end()
into a single function, we now have a single user of
ext4_generic_write_end(), so we can now fold ext4_generic_write_end()
into ext4_write_end().

						- Ted

  reply	other threads:[~2013-02-22 15:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21  8:01 [PATCH] ext4: fix free clusters calculation in bigalloc filesystem Lukas Czerner
2013-02-21 12:15 ` [PATCH] ext4: fix overhead calculation in bigalloc filesystem (Re: ... ) Zheng Liu
2013-02-21 12:40   ` Lukáš Czerner
2013-02-21 12:50     ` Lukáš Czerner
2013-02-21 12:52       ` Lukáš Czerner
2013-02-21 13:49         ` Zheng Liu
2013-02-21 14:56           ` Lukáš Czerner
2013-02-22  3:03             ` Zheng Liu
2013-02-22  4:05               ` Theodore Ts'o
2013-02-22  8:04                 ` Lukáš Czerner
2013-02-22 13:18                 ` Zheng Liu
2013-02-22 15:20                   ` Theodore Ts'o [this message]
2013-02-22 16:26                     ` Zheng Liu
2013-03-24 12:29                     ` [PATCH] ext4: fold ext4_generic_write_end into ext4_write_end Zheng Liu
2013-03-25  0:07                       ` Theodore Ts'o
2013-02-21 13:12     ` [PATCH] ext4: fix overhead calculation in bigalloc filesystem (Re: ... ) Zheng Liu
2013-02-22  5:10 ` [PATCH] ext4: fix free clusters calculation in bigalloc filesystem Theodore Ts'o
2013-02-22  7:57   ` Lukáš Czerner
2013-02-22  8:39 ` [PATCH v2] " Lukas Czerner

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=20130222152042.GA19264@thunk.org \
    --to=tytso@mit.edu \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    /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).