[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100722085007.GC903@ZenIV.linux.org.uk>
Date: Thu, 22 Jul 2010 09:50:07 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Artem Bityutskiy <dedekind1@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCHv6 0/9] kill unnecessary SB sync wake-ups + cleanups
On Thu, Jul 22, 2010 at 10:54:40AM +0300, Artem Bityutskiy wrote:
> On Mon, 2010-07-05 at 15:14 +0300, Artem Bityutskiy wrote:
> > here is v6 of my SB sync wakups killing patches, v5 may be found:
> > http://marc.info/?l=linux-fsdevel&m=127583599911620&w=2
> >
> > This is more of a reminder re-send, I did not get any feed-back for
> > v5. Not much changes since v5:
> >
> > 1. Drop patches which fix race conditions for s_dirty changes WRT actual
> > write-back - these things are independent and I am planning to go through
> > that separately.
> > 2. Add "Acked-by" to the btrfs patch.
> > 3. Fold all per-fs patches which introduce SB accessors into one big patch.
>
> Hi Al,
>
> you "unofficially" told me that you want to get rid of '->write_super()'
> and 'sync_supers()' should not exist. And FSes which really need
> '->write_super()' should implement that themselves.
>
> I will try to work on this, but a bit later, after my holidays. But
> could you please:
>
> 1. confirm that you want to kill '->write_super()' and '->s_dirt'
> "officially", so that I could refer to this when sending patches
ACK.
> 2. pick up patches 1-6 from this series, this would make my life easier
> a bit.
>
> I'm not sure then what do do with:
Will be in for-next tonight.
> commit 140236b4b1c749c9b795ea3d11558a0eb5a3a080
> Author: Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
> Date: Thu Jun 10 13:56:33 2010 +0300
>
> VFS: introduce s_dirty accessors
>
> which Linus merged, but which is now not needed, since you now want me
> to kill '->write_super()' completely. Will you take care of this please?
Once that stuff is done, we'll be able to get rid of those just fine..
FWIW, I'm tempted to add affs_dirty_sb()/affs_clean_sb()/affs_is_clean() and
corresponding helpers for other filesystems in the series and fold conversions
to those into your 1--6; you'll need insertion points for your "schedule
some work" logics whether it's done on per-fs-type basis or globally...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists