On Sat, 6 Mar 2010, Jï¿œrn Engel wrote:
> 1) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
> and apply the patch at the bottom yourself.
Not quite - it needs to be applied while merging, rather than applied
separately. It's a conflict, even though it's not a data-conflict, but a
But that's trivial enough. "git pull --no-commit" + fixup + "git commit"
is trivially done, now that I was fore-warned. Thanks.
> 2) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34
> A tree with the patch applied that won't work standalone but will work
> after being pulled into your tree (tested locally).
No, that's horrible. Unbisectable. Not that anybody probably cares in this
case, but it's fundamentally wrong to merge something that doesn't work
before the merge.
> 3) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34_alternative
> A tree that merged your tree and the logfs tree, then has the patch
> applied. Works standalone but has an additional merge commit.
That's ok, but I already did the trivial merge, which actually had another
conflict too (which showed up as a real data conflict on the Kconfig
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ok, learned something new again. Thank you for doing the trivial merge
that would have taken me days to figure out. :)
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
in principle this should be a simple pull request. But as Stephen
noted, the logfs tree conflicts with a patch from hch and I am unsure
how best to proceed.
On Mon, 1 March 2010 16:04:45 +1100, Stephen Rothwell wrote:
> I am carrying a few merge fixup patches in linux-next that I thought you
> might want a heads up about. Hopefully, these will be fixed before you
> see them, but just in case, here they are (in no particular order).
> This could also be taken as a reminder to the respective maintiners that
> they may want to do a merge of your tree before asking you to pull theirs.
> 5) The vfs tree modifies the write_inode method API (commit
> 716c28c0bc8bcbdd26e819f38dfc8fdfaafc0289 "pass writeback_control to
> ->write_inode") and the logfs tree adds a write_inode method (commit
> 5db53f3e80dee2d9dff5e534f9e9fe1db17c9936 "[LogFS] add new flash file
> system"), so:
I see three solutions that are remotely sane.
1) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
and apply the patch at the bottom yourself.
A tree with the patch applied that won't work standalone but will work
after being pulled into your tree (tested locally).
A tree that merged your tree and the logfs tree, then has the patch
applied. Works standalone but has an additional merge commit.
I would slightly prefer option 2), but you surely know better.
PS: And trees 2) and 3) haven't made it over from master.kernel.org yet.
Not sure if I made a mistake or simply have to wait longer.
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan
From aaaa4c850bbe2e02aca24b681180258d1671b15e Mon Sep 17 00:00:00 2001
From: Joern Engel <jo...@logfs.org>
Date: Sat, 6 Mar 2010 21:25:08 +0100
Subject: [PATCH] [LogFS] Follow write_inode changes
Commit a9185b41a4f84971b930c519f0c63bd450c4810d changed the
fs/logfs/inode.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/logfs/inode.c b/fs/logfs/inode.c
index 6d08b37..33ec1ae 100644
@@ -282,7 +282,7 @@ struct inode *logfs_read_meta_inode(struct super_block *sb, u64 ino)
-static int logfs_write_inode(struct inode *inode, int do_sync)
+static int logfs_write_inode(struct inode *inode, struct writeback_control *wbc)
long flags = WF_LOCK;
On Sat, 6 Mar 2010, Jörn Engel wrote:
> Ok, learned something new again. Thank you for doing the trivial merge
> that would have taken me days to figure out. :)
Heh. I do those things day in and day out. That was a really easy merge.
And I'm happy you pointed it out beforehand, so that we didn't get a
separate commit and non-bisectable history.
I have a dozen fixes for you. Some solve error path bugs, some are
necessary for the SSD that I never wanted to buy but finally did anyway
and the rest solve rather nasty bugs.
Al still has one error path problem I haven't dealt with yet.
dev_bdev.c | 9 +++++++--
dir.c | 4 ++--
journal.c | 7 +++++++
logfs.h | 1 +
readwrite.c | 13 ++++++++++++-
segment.c | 54 +++++++++++++++++++++++++++++++-----------------------
super.c | 15 +++++++--------
7 files changed, 67 insertions(+), 36 deletions(-)
Joern's library part 11: