Date: Tue, 27 Feb 2007 17:13:02 -0500 From: "Marty Landman" <martster@gmail.com> To: "Jerry McAllister" <jerrymc@msu.edu> Cc: Ian Smith <smithi@nimnet.asn.au>, freebsd-questions@freebsd.org Subject: Re: input/output error on hd Message-ID: <70063950702271413w7715909dl708b5cf42f445fa6@mail.gmail.com> In-Reply-To: <20070226153652.GA58704@gizmo.acns.msu.edu> References: <20070225182126.GA54901@gizmo.acns.msu.edu> <Pine.BSF.3.96.1070226153206.18258A-100000@gaia.nimnet.asn.au> <20070226153652.GA58704@gizmo.acns.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/26/07, Jerry McAllister <jerrymc@msu.edu> wrote: > > On Mon, Feb 26, 2007 at 04:49:46PM +1100, Ian Smith wrote: > > > > Firstly, Marty, you should run dumpfs(8) on your ad1s1a. Well this didn't raise my spirits too much: %sudo dumpfs /dev/ad1s1a dumpfs: /dev/ad1s1a: could not read superblock to fill out disk % So I can get to all but my "dead" blocks via the DD command and work with it in hex; used to do mainframe assembler programming and don't particularly mind the workout, so to speak. Only with a road map it's not possible. Maybe I should write Ian Dowse and see if he can point me in the right direction (pun intended). Marty :--\ With the -m > > switch, this produces a single line suitable for feeding into newfs with > > all parameters, and is probably worth saving for all slices in case of > > any subsequent emergencies. I've just done that for mine, anyway, along > > with fdisk and boot0cfg -v output, and bsdlabel output for UFS slices. > > Yes. Good call. > I couldn't think of the dumpfs command the other evening when > I was writing, but that is the place to start. Definitely run > that output to a file. It will take some learning to understand > how to follow it out. There are tables somewhere that tell what > each of those things mean and what fields to look in in the raw > data to find each thing - and to write it back if that is what you > will want to do. > > Note that it will tell you in the first line if your filesystem if UFS2 > or something else. > > Good luck - maybe if you are successful, you can write a paper on it > and post it to a web page somewhere. I probably should have way back > when and then I would remember more now. > > ////jerry > > > > > Without the -m switch, feed the output to a file, or less, as it's very > > voluminous. For a 240GB drive, it'll likely be huge. However the data > > at the head is probably what's needed, though I can't make much of it. > > > > This post by Ian Dowse explains how to compute where the superblocks > > are, for a quoted example dumpfs: http://noc.caravan.ru/faq/SBLOCK.html > > > > Note however that Ian is talking about UFS1 (where the superblock offset > > was 32) but if you consult fsck_ffs(8) you'll see (under -b) that for > > UFS2, which you almost certainly would have used, it's at 140 .. I > > gather that's the offset from the start of each cylinder group? > > > > > > > > Also assuming my bad sectors really are > > > > totally bad, wouldn't fsck allow me to mark them as unusable and > move on? > > > > > > No, fsck does not do that. Marking blocks bad happend below the > > > level of the OS - generally in the disk controller itself. It > remaps > > > sectors until it runs out of spares and when it runs out, it starts > > > reporting unrecoverable errors. This is not even reported to the OS > > > until it runs out of spares. > > > > > > The only thing you can do with those bad sectors is to try and figure > > > out if any of them are superblocks. If they are, you can probably > > > rebuild it from other superblock clones. If it is not, it is > probably > > > lost data. In that case try to overwrite the bad sector. If that > > > works, then the sector itself is OK, but the data that was there is > > > gone. If it doesn't work, then it is bad and there is a good chance > > > that more than data got nuked in the power failure - eg, it damaged > > > the disk or controller in some way. > > > > Seeing if fsck_ffs will use any discovered alternate superblocks would > > be the first step, and if so, whether that helps to get it mounted. I'd > > certainly be careful to mount it read-only before trying data recovery! > > > > Since Marty has already been bravely using dd :) rewriting those sectors > > should be easy enough, bearing in mind the apparent off-by-one numbering > > difference between the sectors dd found bad and those fsck reported bad. > > > > > But, the next thing seems to be learning about how to follow the file > > > chains and how to find and read and write superblocks. Alternatively > > > you can decide it isn't worth the effort to recover and try and write > > > over the drive completely - just totally trash it - and see if those > > > bad sectors will write. If you did that, then you would have to > rebuild > > > the slice and partition table and do a newfs before you could again > > > use the drive and everything previously on it would be lost. > > > > Well if a dd rewriting those specific contiguous sectors failed, I doubt > > that newfs would do any better, so the dd is definitely worth a try, but > > I wouldn't write anything further to the fs until all else has failed. > > > > > Good luck. > > > > I can only echo that, again. > > > > > Maybe someone who has some experience in tracking file chains can > > > respond and give you more helpp than can I. > > > > Ditto for that .. I'm now very thoroughly out of my depth here, though > > I've learned a few new things through the exercise. > > > > Maybe mailing Ian Dowse with circumstances and the dumpfs head might be > > worth a try, Marty? See the website committers' page for his address. > > > > Cheers, Ian > > > -- Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster's BBS - http://bbs.face2interface.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70063950702271413w7715909dl708b5cf42f445fa6>