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@xxxxxxxxx> > 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
