All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dewey Sasser <dewey@sasser.com>
To: reiserfs-list@namesys.com
Subject: Help tracking down files on a bad block:  understanding the output of debugreiserfs
Date: Tue, 22 Nov 2005 13:10:05 -0500	[thread overview]
Message-ID: <43835EFD.40906@sasser.com> (raw)

Hello all,

I've recently received a bad block notice from SMARTD and I'm trying to 
track down which files might be affected.  I *think* I have the basic 
process correct but I'm missing the final step -- how to get the inode 
of the affected files.  My skill with Google and man pages got me to 
where I am but seems unequal to my remaining task.

My question is:  is the inode of the file in question found in the 
output of debugreiserfs -1 <blocknum> or is there some other way to get 
the inode?

Attached is a console log documenting the process I'm using so far.  How 
should I interpret this output from debugreiserfs?

Many thanks,

--
Dewey Sasser


    straits messages # grep LBAsect messages.1 | tail -n 1
    Nov  9 09:45:34 straits hda: dma_intr: error=0x40 {
    UncorrectableError }, LBAsect=32378944, sector=28250176
    straits messages # fdisk -ul /dev/hda

    Disk /dev/hda: 122.9 GB, 122942324736 bytes
    255 heads, 63 sectors/track, 14946 cylinders, total 240121728 sectors
    Units = sectors of 1 * 512 = 512 bytes

       Device Boot      Start         End      Blocks   Id  System
    /dev/hda1   *          63      128519       64228+  83  Linux
    /dev/hda2          128520     4128704     2000092+  83  Linux
    /dev/hda3         4128705   240107489   117989392+   5  Extended
    /dev/hda5         4128768    43198784    19535008+  83  Linux
    /dev/hda6        43198848   240107489    98454321   83  Linux
    straits messages # dc
    32378944     /# LBA Sector/
    4128768       /# Starting sector for hda5/
    -
    p
    28250176     /# result:  this is the sector within hda5/
    8                   /# convert 512 byte sectors to 4096 byte
    ReiserFS blocks
    /
    /p
    3531272       # /result:  this is the ReiserFS block containing the
    bad sector/
    q
    straits messages # debugreiserfs -1 3531272 /dev/hda5
    debugreiserfs 3.6.19 (2003 www.namesys.com)

    3531272 is used in ondisk bitmap

    ===================================================================
    LEAF NODE (3531272) contains level=1, nr_items=12, free_space=632
    rdkey (real items 12)
    -------------------------------------------------------------------------------
    |###|type|ilen|f/sp| loc|fmt|fsck|                  
    key                      |
    |   |    |    |e/cn|    |  
    |need|                                            |
    -------------------------------------------------------------------------------
    |  0|3065513 2078685 0x0 SD (0), len 44, location 4052 entry count
    65535, fsck need 0, format new|
    (NEW SD), mode -rw-rw-r--, size 0, nlink 1, mtime 24/2005 04:17:29
    blocks 0, uid 0
    -------------------------------------------------------------------------------
    |  1|3065513 2078685 0x1 DRCT (2), len 456, location 3596 entry
    count 65535, fsck need 0, format new|
    -------------------------------------------------------------------------------
    |  2|3065513 2269255 0x0 SD (0), len 44, location 3552 entry count
    65535, fsck need 0, format new|
    (NEW SD), mode -rw-rw-r--, size 610, nlink 1, mtime 02/2005 04:05:49
    blocks 8, uid 0
    -------------------------------------------------------------------------------
    |  3|3065513 2269255 0x1 DRCT (2), len 616, location 2936 entry
    count 65535, fsck need 0, format new|
    -------------------------------------------------------------------------------
    |  4|3065513 2269421 0x0 SD (0), len 44, location 2892 entry count
    65535, fsck need 0, format new|
    (NEW SD), mode -rw-rw-r--, size 505, nlink 1, mtime 01/2005 14:35:40
    blocks 8, uid 0
    -------------------------------------------------------------------------------
    |  5|3065513 2269421 0x1 DRCT (2), len 512, location 2380 entry
    count 65535, fsck need 0, format new|
    -------------------------------------------------------------------------------
    |  6|3065513 2269440 0x0 SD (0), len 44, location 2336 entry count
    65535, fsck need 0, format new|
    (NEW SD), mode -rw-rw-r--, size 371, nlink 1, mtime 21/2005 14:35:50
    blocks 8, uid 0
    -------------------------------------------------------------------------------
    |  7|3065513 2269440 0x1 DRCT (2), len 376, location 1960 entry
    count 65535, fsck need 0, format new|
    -------------------------------------------------------------------------------
    |  8|3065513 2269513 0x0 SD (0), len 44, location 1916 entry count
    65535, fsck need 0, format new|
    (NEW SD), mode -rw-rw-r--, size 873, nlink 1, mtime 17/2005 16:06:08
    blocks 8, uid 0
    -------------------------------------------------------------------------------
    |  9|3065513 2269513 0x1 DRCT (2), len 880, location 1036 entry
    count 65535, fsck need 0, format new|
    -------------------------------------------------------------------------------
    | 10|3065513 2288540 0x0 SD (0), len 44, location 992 entry count
    65535, fsck need 0, format new|
    (NEW SD), mode -rw-rw-r--, size 643, nlink 1, mtime 09/2005 15:35:43
    blocks 8, uid 0
    -------------------------------------------------------------------------------
    | 11|3065513 2288540 0x1 DRCT (2), len 48, location 944 entry count
    65535, fsck need 0, format new|
    ===================================================================


             reply	other threads:[~2005-11-22 18:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-22 18:10 Dewey Sasser [this message]
2005-11-22 19:00 ` Help tracking down files on a bad block: understanding the output of debugreiserfs Konstantin Münning
2005-11-22 20:22   ` Dewey Sasser

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=43835EFD.40906@sasser.com \
    --to=dewey@sasser.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.