Hallo,
this was my problem:
>Hi all,
>during a backup i got some messages like this :
>Error for command 'read'
>vmunix: sd2g: Error Level: Retryable
>vmunix: sd2g: Block 39578, Absolute Block: 39578
>vmunix: sd2g: Sense Key: Aborted Command
>vmunix: sd2g: Vendor 'IBM' error code: 0x1b
>it is possible to find out the name of the file, which contains the bad blocks ?
most of the answers recommended to use
icheck -b blocknumber #to find out the inodenumber
ncheck -i inodenumber #to get the filename
Another recommandation was to try
tar cvf /dev/null /filesystem|grep error
but this did not work, i think it only works, if the sector is totaly not readable.
Thanks to all who answered
--------------------------
kevin@uniq.com.au
pluto!perryh@qiclab.scn.rain.com
root@wisdom.maf.nasa.gov
mike@trdlnk.com
pln@egret1.Stanford.EDU
nitkin@ptdcs2.intel.com
gunn@lardav.com
jmende01@mcs.eds.com
valdes@geosun.uchicago.edu
Thanh.Huynh@pwc.utc.com
jcarr37863@aol.com
johnh@gerbil.umds.ac.uk
Birger.Wathne@vest.sdata.no
lvsun!cable.lvsun.COM!carl@uunet.uu.net
mshon@sunrock.East.Sun.COM
bismark@alta.jpl.nasa.gov
Best Regards
E.Claudius
-----------------------------+--------------------------------------+
Eduard Claudius |Who is GENERAL FAILURE and why is he |
Systemmanager |reading my Harddisk ? |
-----------------------------+--------------------------------------+
Alfred-Wegener-Institute for | E-mail: claudius@awi-potsdam.de |
Polar and Marine Research | Tel.: +49 331 288 2125 |
Research Department Potsdam | Fax: +49 331 288 2137 |
-----------------------------+--------------------------------------+
An here are the original answers
--------------------------------
----- Begin Included Message -----
>From kevin@uniq.com.au Tue Jul 18 08:50:34 1995
X400-Received: by /PRMD=dkrz/ADMD=d400/C=de/;
Relayed; 18 Jul 95 08:48:35+0200
Date: 18 Jul 95 08:48:35+0200
From: "Kevin Sheehan {Consulting Poster Child}" <Kevin.Sheehan@uniq.com.au>
To: E. Claudius <claudius@AWI-Potsdam.DE>
Subject: Re: Which file contains the bad block ?
X-Mailer: Mail User's Shell (7.1.2 7/11/90)
Content-Length: 573
[ Regarding "Which file contains the bad block ?", claudius@awi-potsdam.de writes on Jul 17: ]
> Hi all,
> during a backup i got some messages like this :
>
> Error for command 'read'
> vmunix: sd2g: Error Level: Retryable
> vmunix: sd2g: Block 39578, Absolute Block: 39578
> vmunix: sd2g: Sense Key: Aborted Command
> vmunix: sd2g: Vendor 'IBM' error code: 0x1b
>
> it is possible to find out the name of the file, which contains the bad blocks ?
icheck -b # tells you the inode #
ncheck -i # tells you the file...
l & h,
kev
----- End Included Message -----
----- Begin Included Message -----
>From pluto!perryh@qiclab.scn.rain.com Wed Jul 19 09:41:18 1995
X400-Received: by /PRMD=dkrz/ADMD=d400/C=de/;
Relayed; 19 Jul 95 09:40:17+0200
X400-Received: by /PRMD=com/ADMD=d400-gw/C=de/;
Relayed; 18 Jul 95 23:20:07-0700
Date: 18 Jul 95 23:20:07-0700
From: Perry Hutchison <perryh@pluto.rain.com>
To: claudius@AWI-Potsdam.DE
Subject: Re: Which file contains the bad block ?
Content-Length: 767
> Error for command 'read'
> vmunix: sd2g: Error Level: Retryable
> vmunix: sd2g: Block 39578, Absolute Block: 39578
> vmunix: sd2g: Sense Key: Aborted Command
> vmunix: sd2g: Vendor 'IBM' error code: 0x1b
>
> it is possible to find out the name of the file, which contains the
> bad blocks ?
This may be the only remaining use for icheck(8) and ncheck(8):
# icheck -b 39578 /dev/rsd2g
will report the i-number of the file containing that block. Then
# ncheck -i XXXX /dev/rsd2g
or
# find {mountpoint} -xdev -inum XXXX -ls
(where XXXX is the i-number reported by icheck) will give you the
pathname. For the second step, find will be faster than ncheck
unless the filesystem is nearly full, but ncheck does not require
the filesystem to be mounted.
----- End Included Message -----
----- Begin Included Message -----
>From root@wisdom.maf.nasa.gov Tue Jul 18 18:29:33 1995
Date: Tue, 18 Jul 95 11:08:13 CDT
From: root@wisdom.maf.nasa.gov (Mark Hargrave)
To: claudius@AWI-Potsdam.DE
Subject: Re: Which file contains the bad block ?
Content-Length: 529
Eduard,
It's hard to find out what file is bad. What you need to do is go
into the format command and repair Absolute Block: 39578.
# format
Specify disk (enter its number):
format> repair
Enter block number of defect: 39578
Thanks, Mark
------------------------------------------
Mark Hargrave, Unix Systems Manager
Lockheed Martin Manned Space Systems
PO Box 29304 Mail Stop: DPI/Bin 41
New Orleans, LA 70189
Phone: 504-257-1242
E-Mail: meh@wisdom.maf.nasa.gov
------------------------------------------
----- End Included Message -----
----- Begin Included Message -----
>From mike@trdlnk.com Tue Jul 18 18:50:36 1995
X400-Received: by /PRMD=dkrz/ADMD=d400/C=de/;
Relayed; 18 Jul 95 18:49:21+0200
X400-Received: by /PRMD=com/ADMD=d400-gw/C=de/;
Relayed; 18 Jul 95 11:05:00-0500
Date: 18 Jul 95 11:05:00-0500
From: Michael Sullivan <mike@trdlnk.com>
To: claudius@AWI-Potsdam.DE
Subject: Re: Which file contains the bad block ?
Content-Length: 1178
>during a backup i got some messages like this :
>
>Error for command 'read'
>vmunix: sd2g: Error Level: Retryable
>vmunix: sd2g: Block 39578, Absolute Block: 39578
>vmunix: sd2g: Sense Key: Aborted Command
>vmunix: sd2g: Vendor 'IBM' error code: 0x1b
>
>it is possible to find out the name of the file, which contains the bad blocks ?
Yes, use the icheck command, like this:
/usr/etc/icheck -b 39578 /dev/rsd2g
note that you need to use the relative block number, not the absolute block.
In this case they happen to be the same, but that is not always the case.
icheck will tell you the inode number of the file containing the block.
You can then find the file name(s) corresponding
to that inode either by using the ncheck command:
/usr/etc/ncheck -i inode_number /dev/rsd2g
or using the find command:
find mount_point -xdev -inum inode_number -print
where mount_point is the mount point for the filesystem in question.
I suspect ncheck would be faster than find.
-- Michael T. Sullivan | email: mike@trdlnk.com TradeLink L.L.C. | voice: +1 312 408 2599 175 W. Jackson, Suite A1235 | fax: +1 312 939 2531 Chicago, Illinois 60604 USA |----- End Included Message -----
----- Begin Included Message -----
>From pln@egret1.Stanford.EDU Tue Jul 18 19:05:55 1995 Date: Tue, 18 Jul 1995 10:04:45 -0700 From: "Patrick L. Nolan" <pln@egret1.Stanford.EDU> To: claudius@AWI-Potsdam.DE Subject: Re: Which file contains the bad block ? Content-Length: 105
Use icheck -b to determine the inode associated with the bad block. Then use ncheck -i to find the file.
----- End Included Message -----
----- Begin Included Message -----
>From nitkin@ptdcs2.intel.com Tue Jul 18 19:56:05 1995 From: Nate Itkin <Nate-Itkin@ptdcs2.intel.com> Subject: Re: Which file contains the bad block ? To: claudius@AWI-Potsdam.DE Date: Tue, 18 Jul 95 10:53:17 PDT X-Anon-Password: ou8nr6yceudba X-Mailer: ELM [version 2.3 PL11] Content-Length: 625
> Hi all, > during a backup i got some messages like this : > Error for command 'read' > vmunix: sd2g: Error Level: Retryable > vmunix: sd2g: Block 39578, Absolute Block: 39578 > vmunix: sd2g: Sense Key: Aborted Command > vmunix: sd2g: Vendor 'IBM' error code: 0x1b > it is possible to find out the name of the file, which contains the > bad blocks ? > Best Regards > E.Claudius
icheck -b 39578 /dev/rsd2g ncheck -i _____ /dev/rsd2g (fill in the blank with the inode # from icheck)
-- - Nate Itkin - Portland Technology Development, Intel Corporation Aloha, Oregon - E-mail: Nate-Itkin@ptdcs2.intel.com
----- End Included Message -----
----- Begin Included Message -----
>From gunn@lardav.com Tue Jul 18 20:02:33 1995 Date: Tue, 18 Jul 1995 12:01:09 -0600 From: gunn@lardav.com (David Gunn) To: claudius@AWI-Potsdam.DE Subject: Re: Which file contains the bad block ? Content-Length: 759
>Hi all, >during a backup i got some messages like this : > >Error for command 'read' >vmunix: sd2g: Error Level: Retryable >vmunix: sd2g: Block 39578, Absolute Block: 39578 >vmunix: sd2g: Sense Key: Aborted Command >vmunix: sd2g: Vendor 'IBM' error code: 0x1b > >it is possible to find out the name of the file, which contains the bad blocks ? > >Best Regards > >E.Claudius
Hmmm. Maybe try doing a tar and looking for an i/o error:
tar -cvf /dev/null /dir >&! /usr/tmp/tar.out
where "dir" is the mount point of the filesystem. When the tar is done, look for "rror" (as in error) in /usr/tmp/tar.out.
Good luck.
-- David Gunn
Company: Larson-Davis, Inc E-mail : david.gunn@lardav.com Voice : 801-375-0177 Fax : 801-375-0182
----- End Included Message -----
----- Begin Included Message -----
>From jmende01@mcs.eds.com Tue Jul 18 20:21:52 1995 Date: Tue, 18 Jul 1995 13:18:54 -0500 From: jmende01@mcs.eds.com (John Mendenhall) To: claudius@AWI-Potsdam.DE Subject: Re: Which file contains the bad block ? X-Sun-Charset: US-ASCII Content-Length: 2250
> during a backup i got some messages like this : > > Error for command 'read' > vmunix: sd2g: Error Level: Retryable > vmunix: sd2g: Block 39578, Absolute Block: 39578 > vmunix: sd2g: Sense Key: Aborted Command > vmunix: sd2g: Vendor 'IBM' error code: 0x1b > > it is possible to find out the name of the file, which contains the bad blocks ?
Run the following script of commands to obtain the file which contains the bad block, using csh commands:
#!/bin/csh #[assumptions: you are using SunOS 4.1.x, based on sd2g disk nomenclature]
set block=[<block number given above in error>] set filesystem=[<disk device for specified disk>]
#[see man pages for icheck if you have questions about this command]
set inode=`icheck -b ${block} ${filesystem} | tr ":=," " " | awk '(($7 == "inode") && ($10 != "free" )) {print $8}'` if ( "$inode" == "" ) then echo FS: $filesystem Block: $block Inode: NONE File: NONE exit 1 endif
#[see man pages for dcheck if you have questions about this command]
set file=`dcheck -i ${inode} ${filesystem} | head -5 | awk '(NR == 2) {print $3}'` if ( "$file" == "cnt" ) then echo FS: $filesystem Block: $block Inode: $inode File: NONE exit 1 endif
set filename=
try_again:
set tmp=`echo $file | tr "/" " "` if ( "$tmp[2]" == "." ) then echo FS: $filesystem Block: $block Inode: $inode File: /$filename exit 0 endif
set hierinode=$tmp[1] if ( "$filename" == "" ) then set filename=$tmp[2] else set filename=$tmp[2]/$filename endif
set file=`dcheck -i ${hierinode} ${filesystem} | head -5 | awk '(NR == 2) {print $3}'` if ( "$file" == "cnt" ) then echo FS: $filesystem Block: $block Inode: $inode [$hierinode] File: NONE [$filename] exit 1 endif
goto try_again
If this just prints out /<filename>, you can run find to get the full pathname of the filename. Or, you can use the inode output along with dcheck to determine the path up the chain. If you have any questions concerning this script, please ask.
JohnM # John E. Mendenhall EDS Management Consulting # # EMail: jmende01@mcs.eds.com Mailstop H3-5D-66 # # Voice: (214) 605-3797 5400 Legacy Drive # # Fax: (214) 605-4506 Plano, TX 75024 #
----- End Included Message -----
----- Begin Included Message -----
>From valdes@geosun.uchicago.edu Tue Jul 18 21:40:59 1995 From: John Valdes <valdes@geosun.uchicago.edu> Subject: Re: Which file contains the bad block ? To: claudius@AWI-Potsdam.DE Date: Tue, 18 Jul 1995 14:36:47 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 13847
> it is possible to find out the name of the file, which contains the bad blocks ?
Yes. I've attached below an old summary which details just how to do this. The procedure works great.
John Valdes valdes@geosun.uchicago.edu
=======================================================================
Date: Fri, 29 Nov 91 16:47:06 GMT From: Dave Mitchell <D.Mitchell@dcs.sheffield.ac.uk> To: sun-managers@eecs.nwu.edu Subject: SUMMARY: finding file associated with disk block
My original query:
> I recently had to repair a bad block on a disk. Unfortunately, > I now have a file with a block of zeros embedded somewhere in it. > I know the block number, I need to find which file is using that block. > I asked sun, they said that there's no command that gives that info. > Has anyone got a program that can scan the i-nodes to find the block? > The machine is running 4.0.3, but I have another disk playing up on a 3.4 > machine as well (I know - not even 3.5 !!!) >
The answer, as many of you pointed out, is
icheck -b <bad_block#> /dev/r...
this lists (amongst other things), the i-node that refers to that block
you can then do
find /mount/point -xdev -inum nnnn -ls or ncheck -i nnnn /dev/r..
to find the file name(s) associated with that inode.
BTW, by a bizarre coincidence, the file I eventually asociated with an (intermittent) bad block, was /bin/find itself!
Finally, Keith Farrar <keith%markets@net.uu.uunet> sent me a document which I have included at the end, on the grounds that it might be of interst to many people, even though its quite long.
Thanks to the countless people who replied (too many to list!)
Dave.
----- Begin Included Message -----
What File Has The Disc Error?
by John Walker Revision 0 -- December 21st, 1989
ABSTRACT ========
When a single block or contiguous area on a Sun (or other Unix) system's hard disc fails, one of the most obvious and immediately important questions that arises is "What file contains the error?". Amazingly, there is no simple, standard utility that answers this question, leaving the user knowing that some data have been destroyed, but not what. If backups are current, the user doesn't know what files to reload after the failed area is reassigned to an alternate track or made unavailable for allocation. This paper presents a cookbook procedure, based on information provided by Bob Elman, for determining which file contains a bad disc block.
INTRODUCTION ============
When my hard disc presented me with its latest holiday surprise, I ended up with 100% repeatable errors on a specific track, head, and sector. Immediately after the error occurred, I ran an incremental backup which, naturally, encountered read errors. At that point I had a current set of backups from which I was perfectly willing to reload or rebuild any files that occupied the area of the disc that had failed, but I didn't know which files were involved. DUMP didn't tell me, when it so kindly reported an error during the backup; even though it clearly knows the INODE number it was dumping when the error occurred, it didn't deign to print it.
Bob Elman explained the procedure one uses to find what file contains a given disc block, and it worked just fine, telling me that the error was in an executable file I could simply re-link after I'd fixed the disc by reformatting the track that failed. Since the procedure is less than obvious and nowhere explained in the Unix manuals I've seen, I decided to write it down so I'd have it at hand the next time this happened, and to help the next poor sucker victimised by a hard disc failure. You might want to print this message on a piece of paper and file it in your system administration manual--when you need it, you may not be able to get it from a file on your disc.
FINDING THE FILE ================
We start out knowing that a hard disc contains one or more bad blocks. The first symptom that something is wrong is usually Unix console messages reporting I/O errors on the drive. Most of these I/O error messages give the block number that failed but since Unix reads and writes large buffers, these numbers should be considered as giving only the general area of the actual error. The first step, then, is to identify the actual blocks that contain the errors.
What Blocks Are Bad? --------------------
(Sun specific.) Initially, note the drive number from the disc error message. In a typical message like:
xd1c: write failed (header not found) -- blk #1317140, abs blk #1317140
the drive name is "xd1c". To find out what file system this corresponds to, type "df", which will print something like:
Filesystem kbytes used avail capacity Mounted on /dev/xd0a 15502 1946 12005 14% / /dev/xd0h 514106 430020 32675 93% /usr /dev/xd1c 659242 569911 23406 96% /usr2 /dev/xd0g 42406 8554 29611 22% /var
In this case, you can see that "xd1c" is mounted as your /usr2 filesystem. (The default mounting of file systems is given by the file /etc/mtab, which you can type.)
Shut down your system and bring it up single user with "b -s". In single user mode, run "format". When you fire up format, it asks you to choose the disc you want to work on; pick the one from the error message. For example:
throop# format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. xd0 at xdc0 slave 0 xd0: <CDC 9720-850 cyl 1358 alt 2 hd 15 sec 66> 1. xd1 at xdc0 slave 1 xd1: <Fujitsu-M2372K cyl 743 alt 2 hd 27 sec 67> Specify disk (enter its number): 1 selecting xd1: <Fujitsu-M2372K> [disk formatted, defect list found]
Here, I've entered "1" to choose "xd1". (The "c" in the error number is a partition name, but at this level format is working on the whole disc.)
Next, we want to get the physical disc address of the block number reported in the error message. Enter the "show" command, and type in the error block number:
format> show Enter a disk block: 1317140 Disk block = 1317140 = 0x141914 = (728/2/54)
This tells us that the block where Unix encountered the error was on track 728, head 2, sector 54. Since we don't know precisely where the error was, we'll sniff around the two surrounding tracks for errors. Enter the surface analysis command:
format> analyze
and then enter "setup" to specify the parameters for the analysis:
analyze> setup Analyze entire disk [yes]? no Enter starting block number [0, 0/0/0]: 727/0/0 Enter ending block number [1347704, 744/26/66]: 729/$/$ Loop continuously [no]? Enter number of passes [2]: 1 Repair defective blocks [yes]? no <========= INCREDIBLY IMPORTANT!!!! <=== Stop after first error [no]? Use random bit patterns [no]? Enter number of blocks per transfer [126, 0/1/59]: 1 Verify media after formatting [yes]? Enable extended messages [no]? Restore defect list [yes]? Restore disk label [yes]?
Here we've set up to scan from the start of track 727 through the end of track 729 (the "$" means "the highest number valid in this field"), reading single sectors. If we were to use a larger blocks, the precise location of the errors would be indeterminate. IT IS ABSOLUTELY ESSENTIAL, SURPASSINGLY SO, THAT YOU ANSWER *NO* TO THE "REPAIR DEFECTIVE BLOCKS" PROMPT. If fail to do this, the so-called "read-only" test will go ahead and "repair" blocks on your disc, possibly causing loss of data in files. So much for reasonable defaults!
Now select the read-only surface analysis:
analyze> read Ready to analyze (won't harm SunOS). This takes a long time, but is interruptable with CTRL-C. Continue? yes
This will scan the tracks you've specified. Since we're only looking at a few tracks, the comment about taking a long time is another lie. This command should report the individual sectors with errors. If it doesn't, welcome to the world of transient disc errors. If it does, note the track, head, and sector numbers of all failing sectors on paper, then leave the analyse command:
analyze> q
You can then convert those addresses back to block numbers with the "show" command:
format> show Enter a disk block: 728/2/22 Disk block = 1317108 = 0x1418f4 = (728/2/22)
Once you have the failing block numbers in hand, you're done with format. This example has been for a disc with a single partition that fills it entirely. If your disc has multiple partitions, you'll have to convert these absolute block numbers to relative numbers based on your partitioning of the disc. The partition/print command will show the current partitioning, which can use to bias the cylinder numbers into their partition-relative addresses.
What I-Node Owns That Block? -----------------------------
On Unix, there is no one-to-one mapping of file names to areas on the disc, since "hard links" can result in a given disc area belonging to any number of named files. The Unix object that most closely corresponds to the notion of a file in most operating systems is called an "I-Node", and it's expressed as a number. The utility "icheck", which was part of the semi-automatic assault guru-driven file recovery facilities of Unix later largely supplanted by "fsck", has the ability to determine what I-Node points to a given block. If you know, for example, that blocks 1317108 and 1317110 on disc "xd1c" contain errors, use the command:
/usr/etc/icheck -b 1317108 1317110 /dev/rxd1c
Bizarre, isn't it? It just scans numbers until it hits the "/" at the start of the disc name. We specified "rxd1c" because naming the "raw device" makes icheck run faster.
Icheck will crunch for some time, and if the specified blocks are part of a file, it will print a line that gives, among other things, the I-node of the file(s) that contain the given blocks. Note the I-nodes on your paper, next to the block numbers. If no I-nodes were reported by this procedure, the error block is not part of any currently existing file.
What File Name(s) Correspond To That I-Node? --------------------------------------------
With the I-Node number in hand, we can finally find out what file was hit. If "icheck" has told us the error is in I-Node 87055, we use the command:
/usr/etc/ncheck -i 87055 -a /dev/rxd1c
to find the file name. After a while, this will print something like:
/dev/rxd1c: 87055 /usr2/kelvin/acadexe/acad
and at last, the inscrutable is unscrewed! The error was in the AutoCAD executable file, which I can simply re-link. If the file hadn't been one so easily recreated, it would have to have been reloaded from the most recent valid backup. Note that if a backup was made after the error occurred, and that file was present on the backup, an earlier backup should be used since the copy on the post-error backup is almost certainly bad.
You can use "ncheck" to search for multiple I-nodes on one pass. For example:
/usr/etc/ncheck -i 4142 4131 4102 -a /dev/rxd0g /dev/rxd0g: 4102 /tmp/vm_fonts-n0 4131 /tmp/tty.txt.a00444 4142 /tmp/rmail
Repairing And Reloading -----------------------
After the location and scope of the damage are established, you should repair the disc errors and restore the damaged files. Since repair procedures are highly system-dependent and, even on Sun systems, differ depending on the type of disc controller and drive installed, you must refer to the hardware documentation for your system for the appropriate procedures.
Note that the Sun documentation talks about "repairing" sectors with errors. Nobody I know can say for sure precisely what this means: whether it's a process of assigning that sector's address to another sector on an alternate track, clearing its availability bit in the current bad spot list, marking it in the original defect list, or what. In addition, the problems I encounter most frequently on hard discs are destroyed headers due to failed writes (for example, when the power fails during a write), which are best fixed by reformatting the area containing the errors rather than discarding sectors which have no physical defects.
In any case, after you've repaired the problem with the disc, you need to delete all the files containing destroyed data and reload them from their most recent backups. As noted above, don't use any backups of error-containing files made after the error occurred, as they probably contain the same errors as the disc controller was complaining about. ----------------------- End Included Text -------------------------------------
______________________________________________________________________ | Keith Farrar | | AMIX Corporation | | Palo Alto, CA "Apple is like the Chinese Cultural | | (415) 856-1234 x217 Revolution conducted by people in | | three-piece suits." | | DOMAIN: keith@markets.amix.com -John Perry Barlow | | UUCP: {uunet|sun|xanadu!}markets!keith | ----------------------------------------------------------------------
----- End Included Message -----
----- End Included Message -----
----- Begin Included Message -----
>From Thanh.Huynh@pwc.utc.com Tue Jul 18 22:54:50 1995 Date: 18 Jul 1995 15:32:18 -0400 (EDT) From: Thanh.Huynh@pwc.utc.com (Thanh Huynh) Subject: Re: Which file contains the bad block ? To: claudius@AWI-Potsdam.DE ("E. Claudius") X-Envelope-To: claudius@awi-potsdam.de Content-Transfer-Encoding: 7BIT X-Mailer: Elm [revision: 109.14] Content-Length: 491
> Hi all, > during a backup i got some messages like this : > > Error for command 'read' > vmunix: sd2g: Error Level: Retryable > vmunix: sd2g: Block 39578, Absolute Block: 39578 > vmunix: sd2g: Sense Key: Aborted Command > vmunix: sd2g: Vendor 'IBM' error code: 0x1b > > it is possible to find out the name of the file, which contains the bad blocks ? > > Best Regards > > E.Claudius Use
icheck -b 39578 /dev/rsd2g ncheck -i inode_number_as_output_by_icheck Thanh
----- End Included Message -----
----- Begin Included Message -----
>From jcarr37863@aol.com Tue Jul 18 23:57:00 1995 Date: Tue, 18 Jul 1995 17:52:12 -0400 From: jcarr37863@aol.com Posted-Date: Tue, 18 Jul 1995 17:52:12 -0400 Received-Date: Tue, 18 Jul 1995 17:52:12 -0400 Reply-To: jcarr37863@aol.com (JCarr37863) To: "E. Claudius" <claudius@AWI-Potsdam.DE> Subject: Re: Which file contains the bad block ? X-Organization: America Online, Inc. (1-800-827-6364) Content-Length: 106
see if there is a file call defect.lst powerstar inc. gaithersburg maryland 800-209-5556 fax 301-948-0715
----- End Included Message -----
----- Begin Included Message -----
>From johnh@gerbil.umds.ac.uk Tue Jul 18 13:35:37 1995 Date: Tue, 18 Jul 1995 12:34:08 +0100 (BST) From: John Hearns <johnh@umds.ac.uk> X-Sender: johnh@lemming To: "E. Claudius" <claudius@AWI-Potsdam.DE> Subject: Re: Which file contains the bad block ? Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 261
Nae problem Jimmy.
The way I do it is to
tar cvf /dev/null /dodgydisk
ie. tar cvf the suspect area to /dev/null
Then look for the errors to appear in the output!
A sophisticated person would even
tar cvf /dev/null /dodgydisk | grep error
John Hearns
----- End Included Message -----
----- Begin Included Message -----
>From Birger.Wathne@vest.sdata.no Tue Jul 18 13:41:47 1995 X400-Received: by /PRMD=dkrz/ADMD=d400/C=de/; Relayed; 18 Jul 95 13:37:08+0200 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; 18 Jul 95 10:24:15+0200 Date: 18 Jul 95 10:24:15+0200 From: Birger A. Wathne <Birger.Wathne@vest.sdata.no> To: claudius@AWI-Potsdam.DE Subject: Re: Which file contains the bad block ? Content-Length: 120
Look up icheck and ncheck to find the inode number the block belongs to, and then the file name of the inode.
Birger
----- End Included Message -----
----- Begin Included Message -----
>From lvsun!cable.lvsun.COM!carl@uunet.uu.net Tue Jul 18 13:46:46 1995 Date: Tue, 18 Jul 95 03:47:40 PDT From: carl@cable.lvsun.COM (carl shapiro x4655) To: claudius@AWI-Potsdam.DE Subject: Re: Which file contains the bad block ? Newsgroups: info.sun-managers Organization: Las Vegas Sun Cc: Content-Length: 267
In article <9507171201.AA14300@pots1.AWI-Potsdam.DE> you write: >it is possible to find out the name of the file, which contains the bad blocks ?
Sure. Use icheck(8) to convert the block number to inode, and then convert that to a filename with ncheck(8).
-- Carl
----- End Included Message -----
----- Begin Included Message -----
>From mshon@sunrock.East.Sun.COM Tue Jul 18 16:54:22 1995 Date: Tue, 18 Jul 1995 10:52:23 -0400 From: mshon@sunrock.East.Sun.COM (Michael J. Shon {*Prof Services} Sun Rochester) To: claudius@AWI-Potsdam.DE Subject: Re: Which file contains the bad block ? Cc: mshon@sunrock.East.Sun.COM X-Sun-Charset: US-ASCII Content-Length: 1707
If this is a SunOS 4.x machine : find out the affected inode icheck -b 39578 /dev/rsd2g if the block is allocated to a file, icheck will give an inode number, in this example: 12345
find out the name of that inode ncheck -i 12345 /dev/rsd2g
I have not found an equivalent for icheck in Solaris 2 :-(
Michael Shon (716) 385-5065 michael.shon@East.Sun.COM
Any information or views presented here derive from my own experience, and are definitely NOT official Sun recommendations or policies.
----- End Included Message -----
----- Begin Included Message -----
>From bismark@alta.jpl.nasa.gov Tue Jul 18 17:32:14 1995 Date: Tue, 18 Jul 95 08:33:09 PDT From: bismark@alta.jpl.nasa.gov (Bismark Espinoza) To: claudius@AWI-Potsdam.DE Subject: Re: Which file contains the bad block ? Cc: bismark@alta.jpl.nasa.gov Content-Length: 105
Use icheck and ncheck to find out the inode number and file. Only relative block numbers are meaningful.
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:29 CDT