Re: logfs unmount bug

["Jörn Engel" <joern@logfs.org>]

On Thu, 1 September 2011 11:38:39 +0530, srimugunthan dhandapani wrote:
> 
> Its frustrating when you ask me to take a new set of logs without
> reading my previous mails.
> To repeat, iam not able to reproduce the third bug. I think the first
> two bugs should be reproducible at your end.

Well, so far I have basically ignored your second and third bug.  As
long as the first is unresolved, I don't want to add yet more
confusion to what we already have.

> I thought that you were asking me to take the logs because you are not
> able to reproduce them too.

I wanted to ask you to take the test patch, run it, see the debug
output in the kernel log and send it to me.  "Take the logs" may have
been what I said, but if I did that would have been too ambiguous.  A
single line of output from the debug printk would have been enough, or
maybe a pagefull.  Certainly not megabytes worth.

> Out of curiosity, are you able to run bonnie successfully with logfs+nandsim?

Yes and no.  I think I have to apologize for using block2mtd so far.
There shouldn't be a big difference between one mtd driver and another
wrt. logfs behaviour.  Famous last words.

The problem with nandsim + logfs is the default segment size.  16k is
not enough to fit an entire journal commit into.  You can try this
yourself by using "mklogfs -s14 /dev/mtd0" or "mklogfs -s15 /dev/mtd0"
in your test scripts.  The first should run into the infinite loop you
experienced, while the second should work.

I'm not entirely sure what to do about this.  The easiest and probably
most robust solution is to check for segment size at mount time and
fail for anything <32k.

Oh, and you might want to add the patch below.

Jörn

-- 
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918

[PATCH] logfs: add mtd_write_sb

Fairly obvious, given the benefit of hindsight. :(

Signed-off-by: Joern Engel <joern@logfs.org>
---
 fs/logfs/dev_mtd.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/fs/logfs/dev_mtd.c b/fs/logfs/dev_mtd.c
index 5ca422c..50a3c8c 100644
--- a/fs/logfs/dev_mtd.c
+++ b/fs/logfs/dev_mtd.c
@@ -228,6 +228,15 @@ static void mtd_writeseg(struct super_block *sb, u64 ofs, size_t len)
 	__mtd_writeseg(sb, ofs, ofs >> PAGE_SHIFT, len >> PAGE_SHIFT);
 }
 
+static int mtd_write_sb(struct super_block *sb, struct page *page)
+{
+	struct mtd_info *mtd = logfs_super(sb)->s_mtd;
+
+	if (mtd->sync)
+		mtd->sync(mtd);
+	return 0;
+}
+
 static void mtd_put_device(struct logfs_super *s)
 {
 	put_mtd_device(s->s_mtd);
@@ -255,6 +264,7 @@ out:
 static const struct logfs_device_ops mtd_devops = {
 	.find_first_sb	= mtd_find_first_sb,
 	.find_last_sb	= mtd_find_last_sb,
+	.write_sb	= mtd_write_sb,
 	.readpage	= mtd_readpage,
 	.writeseg	= mtd_writeseg,
 	.erase		= mtd_erase,
-- 
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html