From: Oleg Drokin <green@namesys.com>
To: Sebastian Kanthak <sebastian.kanthak@muehlheim.de>
Cc: reiserfs-list@namesys.com
Subject: Re: vs-3050: wait_buffer_until_released
Date: Wed, 19 Feb 2003 09:41:25 +0300 [thread overview]
Message-ID: <20030219094125.C24598@namesys.com> (raw)
In-Reply-To: <200302181840.47996.sebastian.kanthak@muehlheim.de>
Hello!
On Tue, Feb 18, 2003 at 06:40:47PM +0100, Sebastian Kanthak wrote:
> I'm using a vanilla 2.4.20 kernel with reiserfs on lvm. I can reproducably
> crash the system by accessing the reiserfs-partition via samba. If I do this,
Can you make the crash info available (oops or whatever you define as "crash").
> the following message appears in the kernel log and repeats every 5 or 10
> seconds.
> Feb 18 11:11:10 manticore kernel: vs-3050: wait_buffer_until_released: nobody
> releases buffer (dev 3a:01, size 4096, blocknr 128036, count 2, list 0, state
> 0x10019, page c1108284, (UPTODATE, CLEAN, UNLOCKED)). Still waiting
> (60000000) JDIRTY !JWAIT
Sure, if one of the threads crashed holding a buffer, other threads waiting for the
buffer would never succeed.
> The only way to stop the machine is to hit the reset button, as every process
> that accesses the reiserfs-partition freezes and cannot be killed, including
> shutdown.
This is kind of "that's how it works in linux if kernel crashed"
> ###########
> reiserfsck --check started at Tue Feb 18 18:09:32 2003
> ###########
> Replaying journal..
> 0 transactions replayed
> Checking internal tree..finished
> Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.
> Checking Semantic tree:
> finished
> 1 found corruptions can be fixed with --fix-fixable
> ###########
> reiserfsck finished at Tue Feb 18 18:26:47 2003
> ###########
> Should I fix the bitmap thing? Is it the reason or the consequence from the
You may or may not. If you won't, there will be some "lost" space on the filesystem.
> above problem. We've changed to reiserfs one day ago, so I'm afraid that the
> problem will reappear, even if I fix it with reiserfsck.
Sure, that's why we are interested in crash information, so that we can understand
it's source and fix the problem if it is reiserfs fault, or if it is the problem
that lies elsewhere, we will ping whoever is the responsible party.
> I've searched the mailing list archives and found others with the same
> problem, however, no solution yet. Do you know the reason for the problem?
Yes. The problem is that reiserfs is waiting on the buffer that is never released.
It is supposedly never released because you had a crash that killed the thread that
acquired the buffer, but have not released it yet.
Thank you.
Bye,
Oleg
next prev parent reply other threads:[~2003-02-19 6:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-18 17:40 vs-3050: wait_buffer_until_released Sebastian Kanthak
2003-02-19 6:41 ` Oleg Drokin [this message]
2003-02-19 8:22 ` Oleg Drokin
2003-02-19 13:26 ` Sebastian Kanthak
2003-02-19 13:49 ` Oleg Drokin
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=20030219094125.C24598@namesys.com \
--to=green@namesys.com \
--cc=reiserfs-list@namesys.com \
--cc=sebastian.kanthak@muehlheim.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.