All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Konstantin Münning" <konstantin@muenning.com>
To: Dewey Sasser <dewey@sasser.com>
Cc: reiserfs-list@namesys.com
Subject: Re: Help tracking down files on a bad block:  understanding the output of debugreiserfs
Date: Tue, 22 Nov 2005 20:00:57 +0100	[thread overview]
Message-ID: <43836AE9.5020403@muenning.com> (raw)
In-Reply-To: <43835EFD.40906@sasser.com>

Hi!

Unfortunately I can't help you with the debugreiserfs output but maybe
with another approach for finding the correct blocknum of the bad
sector(s). Why don't you try

badblocks -b 4096 /dev/hda5

I'm not telling that your approach is wrong but this way (assuming your
reiserfs block is the default 4k) you'll be sure to have all bad blocks.
But it takes some time. On the other hand you may try this:

dd of=/dev/null if=/dev/hda5 bs=4k count=1 skip=xxx

with xxx the block number(s) of your calculation or output from
badblocks. Just to check if the block you've found is really unreadable.

How to identify the inode number corresponding to that block I can't
tell but finding the file etc. to the inode may be done with

find /mount-point-of-fs -inum xxx

where xxx is the inode number in question. See man find.

Hope that helps.
Konstantin

Dewey Sasser wrote:
> 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 19:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-22 18:10 Help tracking down files on a bad block: understanding the output of debugreiserfs Dewey Sasser
2005-11-22 19:00 ` Konstantin Münning [this message]
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=43836AE9.5020403@muenning.com \
    --to=konstantin@muenning.com \
    --cc=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.