From patchwork Thu Sep 1 21:34:20 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?J=C3=B6rn_Engel?= X-Patchwork-Id: 112993 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 003FEB6F88 for ; Fri, 2 Sep 2011 07:33:58 +1000 (EST) Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QzEtL-0000Xn-Ol; Thu, 01 Sep 2011 21:33:44 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QzEtL-0004FC-AW; Thu, 01 Sep 2011 21:33:43 +0000 Received: from [85.183.114.52] (helo=Dublin.logfs.org) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QzEtI-0004Es-1e for linux-mtd@lists.infradead.org; Thu, 01 Sep 2011 21:33:41 +0000 Received: from joern by Dublin.logfs.org with local (Exim 4.72) (envelope-from ) id 1QzEtw-0008KD-5n; Thu, 01 Sep 2011 23:34:20 +0200 Date: Thu, 1 Sep 2011 23:34:20 +0200 From: =?utf-8?B?SsO2cm4=?= Engel To: srimugunthan dhandapani Subject: Re: logfs unmount bug Message-ID: <20110901213420.GA30947@logfs.org> References: <20110816171707.GU26160@logfs.org> <20110826194910.GE22411@logfs.org> <20110831055854.GA12713@logfs.org> <20110831074902.GA26382@logfs.org> <20110831141731.GA29862@logfs.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110901_173340_448036_587074F3 X-CRM114-Status: GOOD ( 22.08 ) X-Spam-Score: 1.3 (+) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (1.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS Cc: linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.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 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,