LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Edward Shishkin <edward@namesys.com>
To: Zan Lynx <zlynx@acm.org>, Andrew Morton <akpm@osdl.org>
Cc: "Vladimir V. Saveliev" <vs@namesys.com>,
reiserfs-list@namesys.com,
Linux kernel mailing list <linux-kernel@vger.kernel.org>,
Reiserfs-dev <reiserfs-dev@namesys.com>
Subject: Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Date: Thu, 01 Feb 2007 18:54:41 +0300 [thread overview]
Message-ID: <45C20D41.6040608@namesys.com> (raw)
In-Reply-To: <1170267238.22971.1.camel@oberon>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Zan Lynx wrote:
>On Sat, 2007-01-20 at 03:34 +0300, Vladimir V. Saveliev wrote:
>
>
>>Hello
>>
>>On Friday 19 January 2007 20:58, Zan Lynx wrote:
>>
>>
>>>I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
>>>and rc4-mm1 have been giving me these freezes. They were happening
>>>inside X and without external console it was impossible to get anything,
>>>plus I was reluctant to test it since the freeze sometimes requires a
>>>full fsck.reiser4 --build-fs to recover the filesystem.
>>>
>>>But I finally got some output in a console session. I wasn't able to
>>>get it all, I made some notes of what I think the problem is. I may try
>>>again later once I get netconsole working (netconsole fails as a
>>>built-in, I'll try it as a module next).
>>>
>>>
>[snip]
>
>
>>yes, please provide more information. Full kernel output at time of freeze is very desirable.
>>
>>
>
>Here comes a full sized bug report, as best as I can do it. This is
>kernel 2.6.20-rc6-mm3 instead of rc4-mm1. Still has the problem.
>
>
Thanks for the dump.
>[ 3138.456588] [<ffffffff8033f5de>] current_atom_finish_all_fq+0x12e/0x280
>[ 3138.456661] [<ffffffff80296510>] autoremove_wake_function+0x0/0x30
>[ 3138.456674] [<ffffffff803350ac>] submit_wb_list+0x11c/0x130
>[ 3138.456690] [<ffffffff80335409>] reiser4_txn_end+0x349/0x530
>[ 3138.456710] [<ffffffff803355f9>] reiser4_txn_restart+0x9/0x20
>[ 3138.456781] [<ffffffff80335680>] force_commit_atom+0x50/0x60
>[ 3138.456793] [<ffffffff8034cfb1>] writepages_unix_file+0x671/0x780
>[ 3138.456824] [<ffffffff802590b3>] do_writepages+0x43/0x80
>[ 3138.456838] [<ffffffff8024dbf8>] __filemap_fdatawrite_range+0x58/0x70
>[ 3138.456914] [<ffffffff8024e19d>] do_fsync+0x3d/0xe0
>[ 3138.456930] [<ffffffff802c2473>] sys_msync+0x143/0x1f0
>[ 3138.456945] [<ffffffff8025c11e>] system_call+0x7e/0x83
>
>
This is waiting for IO completion, and no success because of new plugging
policy introduced by block layer folks. The attached patch should help.
Andrew, please apply.
Thanks,
Edward.
[-- Attachment #2: reiser4-vs-git-block3.patch --]
[-- Type: text/x-patch, Size: 1972 bytes --]
Signed-off-by: Edward Shishkin <edward@namesys.com>
---
linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c | 2 ++
linux-2.6.20-rc6-mm3/fs/reiser4/wander.c | 18 +++++++++++-------
2 files changed, 13 insertions(+), 7 deletions(-)
--- linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c
@@ -63,6 +63,7 @@
}
lock_page(page);
submit_bio(READ, bio);
+ blk_replug_current_nested();
wait_on_page_locked(page);
if (!PageUptodate(page)) {
warning("green-2007",
@@ -157,6 +158,7 @@
lock_page(get_super_private(sb)->status_page); // Safe as nobody should touch our page.
/* We can block now, but we have no other choice anyway */
submit_bio(WRITE, bio);
+ blk_replug_current_nested();
return 0; // We do not wait for io to finish.
}
--- linux-2.6.20-rc6-mm3/fs/reiser4/wander.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/wander.c
@@ -718,6 +718,7 @@
jnode *first, int nr, const reiser4_block_nr *block_p,
flush_queue_t *fq, int flags)
{
+ int ret = 0;
struct super_block *super = reiser4_get_current_sb();
int write_op = ( flags & WRITEOUT_BARRIER ) ? WRITE_BARRIER : WRITE;
int max_blocks;
@@ -738,9 +739,10 @@
int nr_used;
bio = bio_alloc(GFP_NOIO, nr_blocks);
- if (!bio)
- return RETERR(-ENOMEM);
-
+ if (!bio) {
+ ret = RETERR(-ENOMEM);
+ break;
+ }
bio->bi_bdev = super->s_bdev;
bio->bi_sector = block * (super->s_blocksize >> 9);
for (nr_used = 0, i = 0; i < nr_blocks; i++) {
@@ -843,8 +845,10 @@
reiser4_submit_bio(write_op, bio);
not_supported = bio_flagged(bio, BIO_EOPNOTSUPP);
bio_put(bio);
- if (not_supported)
- return -EOPNOTSUPP;
+ if (not_supported) {
+ ret = -EOPNOTSUPP;
+ break;
+ }
}
block += nr_used - 1;
@@ -855,8 +859,8 @@
}
nr -= nr_used;
}
-
- return 0;
+ blk_replug_current_nested();
+ return ret;
}
/* This is a procedure which recovers a contiguous sequences of disk block
next prev parent reply other threads:[~2007-02-01 15:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-19 17:58 Zan Lynx
2007-01-19 18:53 ` Edward Shishkin
2007-01-20 0:34 ` Vladimir V. Saveliev
[not found] ` <1170267238.22971.1.camel@oberon>
2007-02-01 15:54 ` Edward Shishkin [this message]
2007-02-02 0:21 ` Zan Lynx
2007-01-23 7:38 ` Vince
2007-01-23 19:15 ` Vladimir V. Saveliev
2007-01-25 7:33 ` Vince
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=45C20D41.6040608@namesys.com \
--to=edward@namesys.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-dev@namesys.com \
--cc=reiserfs-list@namesys.com \
--cc=vs@namesys.com \
--cc=zlynx@acm.org \
--subject='Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).