thad@cup.portal.com (Thad P Floryan) (11/05/90)
Does anyone know if there's a method (or program) to ascertain to which file on a mounted file system a bad block belongs? The bad block could be specified by any of physical sector, logical block, or cylinder/track/ sector. I'm writing an article to accompany a program which assists mapping out bad blocks (on the 3B1/UNIXPC), and a complete perusal of TFM revealed nothing obvious, nor did the "fsanalyze -e" reveal any inodes whose files' lengths were no longer copacetic due to a bad block now being mapped-out. As you may have guessed, one HD on one system "grew" a bad sector and that prompted the program and the article. 'Twas no big deal to fix, and my program (hdhelper) and article should make it easier for others who encounter their first bad block report, but I'm really curious to what file the bad block was (is?) attached. One discovery in TFM: given an inode number, the ncheck program would reveal the file name. Must the file system be traversed block by block with the (???) program to derive this info? Or am I missing something obvious, such that when a bad block is detected the system (during its current boot incarnation) refuses to re-use the block and/or (somehow) automatically moves recoverable data to another sector. I really don't believe that could happen, but I've been pleasantly surprised by other things in the past, and if someone knows the answer I'll include it in the article. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
kls@ditka.UUCP (Karl Swartz) (11/07/90)
In article <35622@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >Does anyone know if there's a method (or program) to ascertain to which >file on a mounted file system a bad block belongs? The bad block could >be specified by any of physical sector, logical block, or cylinder/track/ >sector. The 'bf' utility should get you close. It only takes logical block numbers, and gives you inode numbers, but it's easy enough to convert from physical sectors or cyl/trk/sec, and once you have the inode it's a simple matter of using 'find -inum nnn' to get the filename. I believe I obtained this from ohio-state; the man page says it was written by Brant Cheikes so that seems likely. -- Karl Swartz |UUCP {uunet,decwrl}!daver!ditka!kls 1-408/223-1308 |INet kls@ditka.chicago.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148
david@twg.com (David S. Herron) (11/11/90)
In article <35622@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >Does anyone know if there's a method (or program) to ascertain to which >file on a mounted file system a bad block belongs? The bad block could >be specified by any of physical sector, logical block, or cylinder/track/ >sector. Part of the inode is a list of logical block numbers allocated to that inode. Therefore, if you have a logical block number, then a traversal of all blocks allocated to inodes will tell you where the block is allocated. Then you use ncheck & that will tell you the file(s) which correspond to that inode. But, probably, as soon as the OS discovers the bad block -- if it does bad block replacement -- then it will replace the logical block, and maybe the block assignment in the inode, behind your back. So the old bad block would no longer be referenced by any inode. I know the SysVr3.2.2 system I've been using does bad block replacement since it was doing that a couple times a week until I replaced the drive. The logical block number -> physical disk address (cyl/track/sector) is done inside the kernel between the file system & disk driver. It's in a routine you cannot access from user level programs. So given a physical disk address it might be hard to come up with the LBN and thus the inode number & file name. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Use the force Wes!
thad@cup.portal.com (Thad P Floryan) (11/14/90)
Seems that with all the other issues and activities recently, I neglected to
post a followup to my query "Ascertaining a file name given a HD block
number."
The solution is actually quite straightforward:
Brant Cheikes' program ``bf'' (block find, version 1.3, available at
the osu-cis archive site) returns the inode(s) of files given the
physical block number, and
either "ncheck" or "find -inum # -print" will return the filepath/name
given the inode number.
In my recent situation I again "lucked out" since the block I spared belonged
to an *.o file, so "nothing" was lost.
During the past several years I've only had two blocks "go bad" amongst some 8
systems and have never lost anything critical (knock on wood! :-)
Which brings me to my favorite exhortation (as many have heard before at
various users' groups meetings here in Silicon Valley) and transcribed from
recordings made at some of the meetings:
`` Hard drives WILL fail; the only uncertainty is when, but it is
guaranteed they WILL fail.
All things mechanical, be they switches, connectors, sockets, cables,
or rotating memories, will wear out or self-destruct at the most
inopportune time in accordance with Murphy's Law and its corollaries.
Your only defense is to develop a system backup regimen and abide it.
The one day you neglect your {sysadmin | operator} duty is the day
your most-valued data develops software rot and bit decay.
And let us not also forget the most dangerous command on the {insert
favorite system name here} is the carriage return; examine what you
have entered BEFORE flailing away at the RETURN key as most commands
are NOT retractable.
...
''
Thad
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]