linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Ext4 Mailing List <linux-ext4@vger.kernel.org>,
	Linux FS Maling List <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Maling List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 0/9] do not use s_dirt in ext4
Date: Thu, 22 Mar 2012 11:06:02 -0400	[thread overview]
Message-ID: <20120322150602.GD25897@thunk.org> (raw)
In-Reply-To: <1332424585.18717.34.camel@sauron.fi.intel.com>

On Thu, Mar 22, 2012 at 03:56:25PM +0200, Artem Bityutskiy wrote:
> 
> But I wonder, since this is cross-FS story, where I need to first do
> small VFS change (export the variable), then change all file-systems,
> and then remove whole 's_dirt'/'write_supers()' stuff from VFS, how this
> would be handled?

What I'm thinking about doing is pulling the first five patches into
my tree, which includes the VFS change to export the
dirty_writeback_interval variable.  Those patches should be very low
risk, and acceptable at this point (although I'm still going to test
them really hard).

Assuming there are no objections with this, then you'd be able to send
the rest of the patches for each file system to get rid of the super
writeback thread separately; those really should go via each file
system maintainer's separate trees, though.  Ext2 and ext3 changes I'm
willing to carry in the ext4 tree (although Jan does have his own ext3
tree).  However, it would really be inappropriate for me to carry
patches against jfs, xfs, or other non-ext 2/3/4 file systems in my
tree.  It will go much faster if you negotiate with each of the file
system maintainers/development teams directly, instead of trying to
use my tree and me as a middleman.

The one thing that will require some coordination is the patch to
completely remove the super writeback thread altogether, which
obviously can't be applied until we know all of the file systems have
removed their dependency on s_dirt.  That's a pretty trivial patch
that could go in late in the next merge window, or even in -rc2 (with
prior warning given to Linus), once you're sure all of the file
systems have gotten their s_dirt removal patches merged in.

Does that seem reasonable to you?

Best regards,

					- Ted

  reply	other threads:[~2012-03-22 15:06 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-20 14:41 [PATCH v1 0/9] do not use s_dirt in ext4 Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 1/9] ext4: do not mark superblock as dirty unnecessarily Artem Bityutskiy
2012-03-22  9:58   ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 2/9] ext4: write superblock only once on unmount Artem Bityutskiy
2012-03-22  9:59   ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 3/9] ext4: remove useless s_dirt assignment Artem Bityutskiy
2012-03-22 10:02   ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 4/9] mm: export dirty_writeback_interval Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 5/9] VFS: remove unused superblock helpers Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 6/9] ext4: introduce __ext4_mark_super_dirty Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 7/9] ext4: stop using VFS for dirty superblock management Artem Bityutskiy
2012-03-21  8:26   ` Artem Bityutskiy
2012-03-20 14:41 ` [PATCH v1 8/9] ext4: small cleanup in ext4_commit_super Artem Bityutskiy
2012-03-22 10:11   ` Jan Kara
2012-03-20 14:41 ` [PATCH v1 9/9] ext4: introduce own superblock dirty flag Artem Bityutskiy
2012-03-22  9:53 ` [PATCH v1 0/9] do not use s_dirt in ext4 Jan Kara
2012-03-22 10:05   ` Artem Bityutskiy
2012-03-22 10:33     ` Jan Kara
2012-03-22 11:25       ` Artem Bityutskiy
2012-03-22 13:42         ` Jan Kara
2012-03-22 13:59           ` Artem Bityutskiy
2012-03-27 13:29       ` Artem Bityutskiy
2012-03-27 20:14         ` Jan Kara
2012-03-28  8:44           ` Artem Bityutskiy
2012-03-28 10:15             ` Jan Kara
2012-03-30 15:23           ` Artem Bityutskiy
2012-03-30 15:35             ` Jan Kara
2012-03-30 15:43               ` Artem Bityutskiy
2012-03-31 11:49                 ` Jan Kara
2012-04-02 13:46                   ` Artem Bityutskiy
2012-03-31 12:25               ` Artem Bityutskiy
2012-03-22 13:35 ` Ted Ts'o
2012-03-22 13:56   ` Artem Bityutskiy
2012-03-22 15:06     ` Ted Ts'o [this message]
2012-03-23  8:55       ` Artem Bityutskiy
2012-03-23 14:23         ` Ted Ts'o

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=20120322150602.GD25897@thunk.org \
    --to=tytso@mit.edu \
    --cc=dedekind1@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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).