From: Oleg Drokin <green@namesys.com>
To: Nick Wellnhofer <nick@paradigmashift.com>
Cc: reiserfs-list@namesys.com
Subject: Re: BUG() in _get_block_create_0
Date: Mon, 23 Dec 2002 19:26:02 +0300 [thread overview]
Message-ID: <20021223192602.C1645@namesys.com> (raw)
In-Reply-To: <3E073A4D.4090704@paradigmashift.com>
Hello!
On Mon, Dec 23, 2002 at 05:31:09PM +0100, Nick Wellnhofer wrote:
> I'm using ReiserFS with the old 3.5 format on a web server. The system
> has been running fine for 2 years. About 1 month ago I upgraded from
> Linux 2.2.16 to 2.4.18 (SuSE 8.1 default kernel). Some weeks ago I got
> reiserfs error messages in syslog suggesting a fsck and I had some files
> which couldn't be accessed or deleted. So last week I ran reiserfsck
> --rebuid-tree. At first everything worked fine. The problematic files
> could be accessed again.
What was reiserfsck version?
> After about 3 hours I got an oops report in my syslog, but the system
> kept running normally. Again 3 hours later the machine crashed with
> another oops. It turned out that the BUG() in _get_block_create_0 in
> fs/reiserfs/inode.c was hit both times. According to the value of EAX
> le_key_k_type (version, key)
> is TYPE_ANY (0x0f) but TYPE_DIRECT (0x02) is expected.
Hm, sounds like FS corruption.
> The machine is a web server in production and I have only remote access,
> so I couldn't run reiserfsck again.
> Any suggestions?
We'd be interested in metadata snapshot
(debugreiserfs -p /dev/your_device | bzip2 -9c >metadata.bz2).
You probably can even do this on readonly-mounted device.
Probably it will even work on read-write mounted device, but
make sure no much write activity is performed on that fs at the time
of snapshot. Also avoid writing metadata to the same fs you are taking
this metadata from ;)
Bye,
Oleg
prev parent reply other threads:[~2002-12-23 16:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-23 16:31 BUG() in _get_block_create_0 Nick Wellnhofer
2002-12-23 16:26 ` Oleg Drokin [this message]
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=20021223192602.C1645@namesys.com \
--to=green@namesys.com \
--cc=nick@paradigmashift.com \
--cc=reiserfs-list@namesys.com \
/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.