Linux NILFS development
 help / color / mirror / Atom feed
From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: WDunphy-/3AnZwnt+WyVkR+q5Y5grQ@public.gmane.org
Cc: konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org,
	users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Subject: Re: Write hang on ARM based target
Date: Fri, 19 Jun 2009 03:36:42 +0900 (JST)	[thread overview]
Message-ID: <20090619.033642.32757627.ryusuke@osrg.net> (raw)
In-Reply-To: <20090612.132344.17157054.ryusuke-sG5X7nlA6pw@public.gmane.org>

Hi,
On Fri, 12 Jun 2009 13:23:44 +0900 (JST), Ryusuke Konishi wrote:
> On Tue, 9 Jun 2009 13:04:04 -0600, "Dunphy, Bill" wrote:
> >  
> > Ryusuke,
> > 
> > I've simplified my test approach by simply copying a single 10 byte file
> > repeatedly.  When doing so, I get consistent NILFS log output at the
> > time of hang.  Examination of /proc/sysreq-trigger also shows the copy
> > process to be in the same state as before (at sys_write).
>
> Thank you for sending me the trace log.  I will look into the problem
> later.
> 
> Ryusuke Konishi

In another thread, I've sent a patch that may cause the hang problem.
Here, I attach the out-of-tree version of the patch.

Does this make a difference in your problem ?

Thanks,
Ryusuke Konishi
--

diff --git a/fs/dat.c b/fs/dat.c
index 036b05d..b05d9d4 100644
--- a/fs/dat.c
+++ b/fs/dat.c
@@ -149,15 +149,6 @@ void nilfs_dat_commit_start(struct inode *dat, struct nilfs_palloc_req *req,
 	entry = nilfs_palloc_block_get_entry(dat, req->pr_entry_nr,
 					     req->pr_entry_bh, kaddr);
 	entry->de_start = cpu_to_le64(nilfs_mdt_cno(dat));
-	if (entry->de_blocknr != cpu_to_le64(0) ||
-	    entry->de_end != cpu_to_le64(NILFS_CNO_MAX)) {
-		printk(KERN_CRIT
-		       "%s: vbn = %llu, start = %llu, end = %llu, pbn = %llu\n",
-		       __func__, (unsigned long long)req->pr_entry_nr,
-		       (unsigned long long)le64_to_cpu(entry->de_start),
-		       (unsigned long long)le64_to_cpu(entry->de_end),
-		       (unsigned long long)le64_to_cpu(entry->de_blocknr));
-	}
 	entry->de_blocknr = cpu_to_le64(blocknr);
 	kunmap_atomic(kaddr, KM_USER0);
 
diff --git a/fs/segment.c b/fs/segment.c
index 3cbb3fe..225d5ae 100644
--- a/fs/segment.c
+++ b/fs/segment.c
@@ -2009,26 +2009,13 @@ static int nilfs_segctor_write(struct nilfs_sc_info *sci,
 		err = nilfs_segbuf_write(segbuf, &wi);
 
 		res = nilfs_segbuf_wait(segbuf, &wi);
-		err = unlikely(err) ? : res;
+		err = unlikely(err) ? err : res;
 		if (unlikely(err))
 			return err;
 	}
 	return 0;
 }
 
-static int nilfs_page_has_uncleared_buffer(struct page *page)
-{
-	struct buffer_head *head, *bh;
-
-	head = bh = page_buffers(page);
-	do {
-		if (buffer_dirty(bh) && !list_empty(&bh->b_assoc_buffers))
-			return 1;
-		bh = bh->b_this_page;
-	} while (bh != head);
-	return 0;
-}
-
 static void __nilfs_end_page_io(struct page *page, int err)
 {
 	if (!err) {
@@ -2056,12 +2043,11 @@ static void nilfs_end_page_io(struct page *page, int err)
 	if (!page)
 		return;
 
-	if (buffer_nilfs_node(page_buffers(page)) &&
-	    nilfs_page_has_uncleared_buffer(page))
-		/* For b-tree node pages, this function may be called twice
-		   or more because they might be split in a segment.
-		   This check assures that cleanup has been done for all
-		   buffers in a split btnode page. */
+	if (buffer_nilfs_node(page_buffers(page)) && !PageWriteback(page))
+		/*
+		 * For b-tree node pages, this function may be called twice
+		 * or more because they might be split in a segment.
+		 */
 		return;
 
 	__nilfs_end_page_io(page, err);
@@ -2125,7 +2111,7 @@ static void nilfs_segctor_abort_write(struct nilfs_sc_info *sci,
 			}
 			if (bh->b_page != fs_page) {
 				nilfs_end_page_io(fs_page, err);
-				if (unlikely(fs_page == failed_page))
+				if (fs_page && fs_page == failed_page)
 					goto done;
 				fs_page = bh->b_page;
 			}

  parent reply	other threads:[~2009-06-18 18:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08 15:46 [SPAM] Write hang on ARM based target Dunphy, Bill
     [not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F8D-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-08 16:49   ` Ryusuke Konishi
     [not found]     ` <20090609.014919.79903506.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-08 20:30       ` Dunphy, Bill
     [not found]         ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F96-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-09 19:04           ` Dunphy, Bill
     [not found]             ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F99-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-12  4:23               ` Ryusuke Konishi
     [not found]                 ` <20090612.132344.17157054.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-18 18:36                   ` Ryusuke Konishi [this message]
     [not found]                     ` <20090619.033642.32757627.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-18 18:42                       ` Ryusuke Konishi
2009-06-18 19:48                       ` Dunphy, Bill
     [not found]                         ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FAC-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-19  1:47                           ` Ryusuke Konishi
     [not found]                             ` <20090619.104731.99018736.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-19 15:01                               ` Dunphy, Bill
     [not found]                                 ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FB3-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-22 18:58                                   ` Dunphy, Bill
     [not found]                                     ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FB9-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-23  3:35                                       ` Ryusuke Konishi
     [not found]                                         ` <20090623.123505.37056161.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-23 15:34                                           ` Dunphy, Bill
     [not found]                                             ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FBB-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-24 21:16                                               ` Dunphy, Bill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090619.033642.32757627.ryusuke@osrg.net \
    --to=ryusuke-sg5x7nla6pw@public.gmane.org \
    --cc=WDunphy-/3AnZwnt+WyVkR+q5Y5grQ@public.gmane.org \
    --cc=konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
    --cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox