From owner-freebsd-fs Sun Oct 28 9:39:16 2001 Delivered-To: freebsd-fs@freebsd.org Received: from bigglesworth.mail.be.easynet.net (bigglesworth.mail.be.easynet.net [212.100.160.67]) by hub.freebsd.org (Postfix) with ESMTP id A330B37B401; Sun, 28 Oct 2001 09:39:12 -0800 (PST) Received: from 212-100-182-16.adsl.easynet.be ([212.100.182.16] helo=belgacom.net) by bigglesworth.mail.be.easynet.net with esmtp (Exim 3.16 #1) id 15xttq-0006A2-00; Sun, 28 Oct 2001 18:39:06 +0100 Message-ID: <3BDC427E.710CE831@belgacom.net> Date: Sun, 28 Oct 2001 18:38:06 +0100 From: Chris Pockele X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: freebsd-gnats-submit@FreeBSD.org, fs@FreeBSD.org Subject: Re: misc/30168: 4-stable, crash when writing to msdos fs References: <3B8CBCAB.97D88562@belgacom.net> <20010829031921.A69280@xor.obsecurity.org> <3B8CD565.A4A52CC6@belgacom.net> <20010829133603.C75228@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Thanks, that was what's needed. Now to find an msdosfs guru to debug > this :) > > Kris > Compiling msdosfs support as a module has solved the problem for a long time (don't know why, but it didn't crash). But after doing a cvsup + makeworld today, it occured again (mounting & reading the msdos partition is ok, panic when writing). I searched the GNATS database and i found a few pr's that seem to describe the same problem. I applied the following patch from pr i386/28536, and it did give me the error message (Next free cluster in FSInfo (%u) exceeds maxcluster (%u)) when trying to mount the partition. The scandisk programs from win98 and w2k don't report any errors on the partitions, and Linux can write to them, too. Should I recompile with unpatched sources and submit another traceback? Here's the patch: /* * Check and validate (or perhaps invalidate?) the fsinfo structure? XXX */ + if (pmp->pm_fsinfo && pmp->pm_nxtfree > pmp->pm_maxcluster) { + printf (" + pmp->pm_nxtfree, pmp->pm_maxcluster); + error = EINVAL; + goto error_exit; + } /* * Allocate memory for the bitmap of allocated clusters, and then Here are the error messages (with patch applied): Oct 28 18:33:35 freedaemon /kernel: Next free cluster in FSInfo (4294967295) exceeds maxcluster (1148401) Oct 28 18:33:49 freedaemon /kernel: Next free cluster in FSInfo (4294967295) exceeds maxcluster (1467070) (there are two msdos partitions which i tried to mount) Maybe it's because the partitions are bigger than 2 or 8 GB? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 29 5:35: 0 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 7E95637B405 for ; Mon, 29 Oct 2001 05:34:57 -0800 (PST) Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtp (Exim 3.33 #1) id 15yCZ4-0001WP-00 for fs@freebsd.org; Mon, 29 Oct 2001 14:34:54 +0100 Received: from ae18f.pppool.de ([213.6.225.143] helo=Magelan.Leidinger.net) by mx1.freenet.de with esmtp (Exim 3.33 #3) id 15yCZ2-0001v7-00 for fs@freebsd.org; Mon, 29 Oct 2001 14:34:53 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.6/8.11.6) with ESMTP id f9TDSGE04238 for ; Mon, 29 Oct 2001 14:28:17 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200110291328.f9TDSGE04238@Magelan.Leidinger.net> Date: Mon, 29 Oct 2001 14:28:15 +0100 (CET) From: Alexander Leidinger Subject: physical block no -> name of file (FFS)? To: fs@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, [Please keep me in the CC] I've a bad block on a harddisk and want to know the name of the file which the bad block is a part of (to replace the file from a backup after writting zeros to the block to remap the block). At http://www.leidinger.net/FreeBSD/b2i.c I've a quick hack which is able to find the slice and partition which contains the bad block, but I don't know what to do now. The idea I have is: - find the dinode which has a relationship to the bad block - find the corresponding directory entry - print the name But I don't know enough about the ffs to do this, what FM should I read to be able to do this (online or basesystem documentation prefered over dead wood docs)? My main problem at the moment is: how does the on disk layout look like? I tried a little bit in b2i.c (state_superblock & state_dinode), but I think this is wrong. Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 29 10:20:30 2001 Delivered-To: freebsd-fs@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id D9E3537B401 for ; Mon, 29 Oct 2001 10:20:26 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA26376; Mon, 29 Oct 2001 10:00:35 -0800 (PST) Date: Mon, 29 Oct 2001 10:00:33 -0800 (PST) From: Julian Elischer To: Alexander Leidinger Cc: fs@freebsd.org Subject: Re: physical block no -> name of file (FFS)? In-Reply-To: <200110291328.f9TDSGE04238@Magelan.Leidinger.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org you would need to start with 'fsck' and add an option to specify a block to watch for (partiton relative). fsck -n -B NUM could easily return an inode number for you and a filename too given enough hacking... Shuould not be toooo difficult, so as you have the itch, if you scratch it, we can take the patches and put them back in so that the next person can do this easier.. julian On Mon, 29 Oct 2001, Alexander Leidinger wrote: > Hi, > > [Please keep me in the CC] > > I've a bad block on a harddisk and want to know the name of the file > which the bad block is a part of (to replace the file from a backup > after writting zeros to the block to remap the block). > > At http://www.leidinger.net/FreeBSD/b2i.c I've a quick hack which is > able to find the slice and partition which contains the bad block, but I > don't know what to do now. > > The idea I have is: > - find the dinode which has a relationship to the bad block > - find the corresponding directory entry > - print the name > > But I don't know enough about the ffs to do this, what FM should I read > to be able to do this (online or basesystem documentation prefered over > dead wood docs)? > > My main problem at the moment is: how does the on disk layout look like? > I tried a little bit in b2i.c (state_superblock & state_dinode), but I > think this is wrong. > > Bye, > Alexander. > > -- > Loose bits sink chips. > > http://www.Leidinger.net Alexander @ Leidinger.net > GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 29 18:55:22 2001 Delivered-To: freebsd-fs@freebsd.org Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by hub.freebsd.org (Postfix) with ESMTP id 36B3937B403 for ; Mon, 29 Oct 2001 18:55:17 -0800 (PST) Received: from jdlim (jdlim.etri.re.kr [129.254.122.173]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 47HHY5MW; Tue, 30 Oct 2001 11:57:34 +0900 Message-ID: <000801c160ef$560430d0$ad7afe81@etri.re.kr> From: "Lim,JaeDeok" To: Subject: [Q]root file system mount(initialization) in booting time. Date: Tue, 30 Oct 2001 12:02:39 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1613A.C591AAE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1613A.C591AAE0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8uIGV2ZXJ5b25lLiENCg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IGZpbGVzeXN0 ZW0gaW5pdGlhbGl6YXRpb24obmFtZWx5LCByb290IGZpbGVzeXN0ZW0gbW91bnQpIGluIEZyZWVC U0QgNC4zLg0KSSBjYW4gc2VlIHRoZSBtZXNzYWdlIHRoYXQgcm9vdCBmaWxlIHN5c3RlbSBpcyBt b3VudGVkLiANClRoZW4gd2hlcmUgaXMgdGhlIHJvdXRpbmUgdGhhdCBwbGF5ZWQgdGhpcyByb2xl Lj8/DQoNCkluIFZGUywgSSB0aGluayAndmZzaW5pdCgpJyByb3V0aW5lIGluICd2ZnNfaW5pdC5j JyBmaWxlIHBsYXkgdGhhdCByb2xlLiBSaWdodD8NCg0KKDEpIFNJX1NVQl9WRlMgICAgICAgICAg ICAgID0gMHg0MDAwMDAwLCAgICAvKiB2aXJ0dWFsIGZpbGUgc3lzdGVtKi8NCigyKSBTWVNJTklU KHZmcywgU0lfU1VCX1ZGUywgU0lfT1JERVJfRklSU1QsIHZmc2luaXQsIE5VTEwpOw0KDQpUaGUg c3lzaW5pdF9zdWJfaWQgb2YgVkZTIGlzIGRlZmluZWQgaW4gJ2VudW0gc3lzaW5pdF9zdWJfaWQg e30nIGluICdrZXJuZWwuaCcgZmlsZSBsaWtlICgxKS4NCkFuZCBWRlMgaXMgb3JkZXJlZCB0byBp bml0aWFsaXplIGJ5ICdTWVNJTklUKCknIG1hY3JvIGluICd2ZnNfaW5pdC5jJyBmaWxlIGxpa2Ug KDIpLg0KDQpJZiB0aGF0J3MgdGhlIGNhc2UsIEhvdyBpcyB0aGUgcm9vdCBmaWxlIHN5c3RlbShl LmcuIFVGUy9GRlMpIG1vdW50ZWQgaW4gYm9vdGluZyB0aW1lPw0KSXMgaXQgbGlrZSB0aGUgVkZT IGluaXRpYWxpemF0aW9uLi4/PyBJZiBzbywgd2hlcmUgPyBob3c/DQoNCkFuZCB0aGVuLCBuZXh0 IHF1ZXN0aW9uIGlzIHRoZSBvcmRlciBiZXR3ZWVuIFZGUyBhbmQgcm9vdCBmaWxlIHN5c3RlbSBp bml0aWFsaXphdGlvbi4NCklzIFZGUyBpbml0aWFsaXphdGlvbiBkb25lIGJlZm9yZSByb290IGZp bGVzeXN0ZW0gbW91bnQgaW4gYm9vdGluZyB0aW1lPw0KT3IgdmljZSB2ZXJzYSAuPw0KDQpQbGVh c2UsIGFuc3dlciBtZSBpbiBkZXRhaWwgaWYgeW91IHBvc3NpYmxlLg0KVGhhbmtzIGluIGFkdmFu Y2UuDQoNCkhhdmUgYSBnb29kIGRheS4NCg== ------=_NextPart_000_0005_01C1613A.C591AAE0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI2MDAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLiBldmVy eW9uZS4hPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCBmaWxlc3lzdGVtIGluaXRpYWxpemF0aW9uKG5h bWVseSwgDQpyb290IGZpbGVzeXN0ZW0gbW91bnQpIGluIEZyZWVCU0QgNC4zLjxCUj5JIGNhbiBz ZWUgdGhlIG1lc3NhZ2UgdGhhdCByb290IGZpbGUgDQpzeXN0ZW0gaXMgbW91bnRlZC4gPEJSPlRo ZW4gd2hlcmUgaXMgdGhlIHJvdXRpbmUgdGhhdCBwbGF5ZWQgdGhpcyANCnJvbGUuPz88L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SW4gVkZTLCBJIHRo aW5rICd2ZnNpbml0KCknIHJvdXRpbmUgaW4gJ3Zmc19pbml0LmMnIGZpbGUgcGxheSANCnRoYXQg cm9sZS4gUmlnaHQ/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPigxKSANClNJX1NVQl9WRlMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo9IDB4NDAwMDAw MCwmbmJzcDsmbmJzcDsmbmJzcDsgLyogdmlydHVhbCBmaWxlIHN5c3RlbSovPEJSPigyKSBTWVNJ TklUKHZmcywgDQpTSV9TVUJfVkZTLCBTSV9PUkRFUl9GSVJTVCwgdmZzaW5pdCwgTlVMTCk7PC9G T05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoZSBzeXNp bml0X3N1Yl9pZCBvZiBWRlMgaXMgZGVmaW5lZCBpbiAnZW51bSBzeXNpbml0X3N1Yl9pZCANCnt9 JyBpbiAna2VybmVsLmgnIGZpbGUgbGlrZSAoMSkuPEJSPkFuZCBWRlMgaXMgb3JkZXJlZCB0byBp bml0aWFsaXplIGJ5IA0KJ1NZU0lOSVQoKScgbWFjcm8gaW4gJ3Zmc19pbml0LmMnIGZpbGUgbGlr ZSAoMikuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PklmIHRoYXQncyB0aGUgY2FzZSwgSG93IGlzIHRoZSByb290IGZpbGUgc3lzdGVtKGUuZy4gVUZT L0ZGUykgDQptb3VudGVkIGluIGJvb3RpbmcgdGltZT88QlI+SXMgaXQgbGlrZSB0aGUgVkZTIGlu aXRpYWxpemF0aW9uLi4/PyBJZiBzbywgd2hlcmUgPyANCmhvdz88L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QW5kIHRoZW4sIG5leHQgcXVlc3Rpb24g aXMgdGhlIG9yZGVyIGJldHdlZW4gVkZTIGFuZCByb290IGZpbGUgDQpzeXN0ZW0gaW5pdGlhbGl6 YXRpb24uPEJSPklzIFZGUyBpbml0aWFsaXphdGlvbiBkb25lIGJlZm9yZSByb290IGZpbGVzeXN0 ZW0gDQptb3VudCBpbiBib290aW5nIHRpbWU/PEJSPk9yIHZpY2UgdmVyc2EgLj88L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+UGxlYXNlLCBhbnN3ZXIg bWUgaW4gZGV0YWlsIGlmIHlvdSBwb3NzaWJsZS48QlI+VGhhbmtzIGluIA0KYWR2YW5jZS48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SGF2ZSBhIGdv b2QgZGF5LjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0005_01C1613A.C591AAE0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 1:21:27 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by hub.freebsd.org (Postfix) with ESMTP id 2A5A037B407 for ; Tue, 30 Oct 2001 01:21:25 -0800 (PST) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtp (Exim 3.33 #1) id 15yV5G-0001fc-00; Tue, 30 Oct 2001 10:21:22 +0100 Received: from b84dc.pppool.de ([213.7.132.220] helo=Magelan.Leidinger.net) by mx3.freenet.de with esmtp (Exim 3.33 #3) id 15yV5G-0002og-00; Tue, 30 Oct 2001 10:21:22 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.6/8.11.6) with ESMTP id f9U9KmD03241; Tue, 30 Oct 2001 10:20:49 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200110300920.f9U9KmD03241@Magelan.Leidinger.net> Date: Tue, 30 Oct 2001 10:20:47 +0100 (CET) From: Alexander Leidinger Subject: Re: physical block no -> name of file (FFS)? To: julian@elischer.org Cc: fs@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 29 Okt, Julian Elischer wrote: > you would need to start with 'fsck' and add an option to specify a block > to watch for (partiton relative). > > fsck -n -B NUM > could easily return an inode number for you and a filename too given > enough hacking... Yes, but I want to do it on a production system. But thanks for the hint, I haven't thought at looking into fsck, will do it later. Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 2:48: 2 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4F1ED37B406 for ; Tue, 30 Oct 2001 02:47:59 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA07140; Tue, 30 Oct 2001 21:47:47 +1100 Date: Tue, 30 Oct 2001 21:46:48 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alexander Leidinger Cc: , Subject: Re: physical block no -> name of file (FFS)? In-Reply-To: <200110300920.f9U9KmD03241@Magelan.Leidinger.net> Message-ID: <20011030213850.U1629-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 30 Oct 2001, Alexander Leidinger wrote: > On 29 Okt, Julian Elischer wrote: > > you would need to start with 'fsck' and add an option to specify a block > > to watch for (partiton relative). > > > > fsck -n -B NUM > > could easily return an inode number for you and a filename too given > > enough hacking... > > Yes, but I want to do it on a production system. Just back up the files and note which ones can't be read. Better, compare them with a previous backup. > But thanks for the hint, I haven't thought at looking into fsck, will do > it later. fsck is not very useful for the original problem of finding files with bad blocks in them, since it only accesses metadata. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 5:43:12 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id EE78E37B408 for ; Tue, 30 Oct 2001 05:43:04 -0800 (PST) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout1.freenet.de with esmtp (Exim 3.33 #1) id 15yZAV-0002c0-00; Tue, 30 Oct 2001 14:43:03 +0100 Received: from b821c.pppool.de ([213.7.130.28] helo=Magelan.Leidinger.net) by mx3.freenet.de with esmtp (Exim 3.33 #3) id 15yZAU-0001ic-00; Tue, 30 Oct 2001 14:43:02 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.6/8.11.6) with ESMTP id f9UD0KD05773; Tue, 30 Oct 2001 14:00:21 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200110301300.f9UD0KD05773@Magelan.Leidinger.net> Date: Tue, 30 Oct 2001 14:00:19 +0100 (CET) From: Alexander Leidinger Subject: Re: physical block no -> name of file (FFS)? To: bde@zeta.org.au Cc: julian@elischer.org, fs@FreeBSD.ORG In-Reply-To: <20011030213850.U1629-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 30 Okt, Bruce Evans wrote: >> > you would need to start with 'fsck' and add an option to specify a block >> > to watch for (partiton relative). >> > >> > fsck -n -B NUM >> > could easily return an inode number for you and a filename too given >> > enough hacking... >> >> Yes, but I want to do it on a production system. > > Just back up the files and note which ones can't be read. Better, compare > them with a previous backup. Yes, this solves my problem (now that I know in which partition the bad block is). But doesn't this need more resources than a dedicated program which only traverses the metadata? On a busy system it may be worthwile to have such a program (and I may be willing to write it). >> But thanks for the hint, I haven't thought at looking into fsck, will do >> it later. > > fsck is not very useful for the original problem of finding files with > bad blocks in them, since it only accesses metadata. And the sequence of blocks which holds the content of a given file isn't included in this metadata? fsck_ffs may give me a hint how the physical representation on the disk looks like (if nobody points me to a better documentation). Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 6:21:10 2001 Delivered-To: freebsd-fs@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 3491537B406 for ; Tue, 30 Oct 2001 06:21:07 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 30 Oct 2001 14:21:05 +0000 (GMT) To: Alexander Leidinger Cc: bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? In-Reply-To: Your message of "Tue, 30 Oct 2001 14:00:19 +0100." <200110301300.f9UD0KD05773@Magelan.Leidinger.net> Date: Tue, 30 Oct 2001 14:21:04 +0000 From: Ian Dowse Message-ID: <200110301421.aa17773@salmon.maths.tcd.ie> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <200110301300.f9UD0KD05773@Magelan.Leidinger.net>, Alexander Leiding er writes: >fsck_ffs may give me a hint how the physical representation on the disk >looks like (if nobody points me to a better documentation). You could try the hacky perl script that I sometimes use for data recovery etc which is at: http://www.maths.tcd.ie/~iedowse/FreeBSD/ufs.pl I'm not sure it will work correctly for you, but it does output block numbers for each file in a filesystem. The output for an inode should look something like ... ino 141227 reclen 0x18 type 010 namelen 14 name 'bsd.gnome.mk,v' 141227 -r--r--r-- 1 1147 0 17465 /Mk/bsd.gnome.mk,v blocks: 0:606824 1:606832 2:606840 3:606848 4:604084 ... where each entry in the "blocks:" list is of the form :, with the "blockno" measured in units of fragments (fs_fsize) from the start of the partition. "lbn" is the offset from the start of the file in units of fs_bsize blocks. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 8: 2:20 2001 Delivered-To: freebsd-fs@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id E997937B403 for ; Tue, 30 Oct 2001 08:02:18 -0800 (PST) Received: from dialup-209.245.128.217.dial1.sanjose1.level3.net ([209.245.128.217] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15ybL7-0001bT-00; Tue, 30 Oct 2001 08:02:10 -0800 Message-ID: <3BDECF33.7A280A2E@mindspring.com> Date: Tue, 30 Oct 2001 08:02:59 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Leidinger Cc: bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? References: <200110301300.f9UD0KD05773@Magelan.Leidinger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alexander Leidinger wrote: [ ... finding bad blocks, using "backup" ... ] > Yes, this solves my problem (now that I know in which partition the bad > block is). > > But doesn't this need more resources than a dedicated program which only > traverses the metadata? On a busy system it may be worthwile to have > such a program (and I may be willing to write it). The problem is that you will have to exhaustively search 50% of all metadata to find a bad block that's contained in a file, and 100% of all metadata, if it's not contained in a file (for example, if it has been replaced by a spare, or the error occurred during a free of the bad block, and the bad block was in metadata, so it held a reference to non-bad blocks). In any case, you are looking at a reverse lookup problem. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 8:22:24 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id AF44837B403 for ; Tue, 30 Oct 2001 08:22:20 -0800 (PST) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.33 #1) id 15ybeZ-0006j0-00; Tue, 30 Oct 2001 17:22:15 +0100 Received: from b821c.pppool.de ([213.7.130.28] helo=Magelan.Leidinger.net) by mx0.freenet.de with esmtp (Exim 3.33 #3) id 15ybeY-0003GP-00; Tue, 30 Oct 2001 17:22:14 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.6/8.11.6) with ESMTP id f9UGKiD07588; Tue, 30 Oct 2001 17:20:45 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200110301620.f9UGKiD07588@Magelan.Leidinger.net> Date: Tue, 30 Oct 2001 17:20:43 +0100 (CET) From: Alexander Leidinger Subject: Re: physical block no -> name of file (FFS)? To: tlambert2@mindspring.com Cc: bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG In-Reply-To: <3BDECF33.7A280A2E@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 30 Okt, Terry Lambert wrote: > The problem is that you will have to exhaustively search 50% of > all metadata to find a bad block that's contained in a file, and > 100% of all metadata, if it's not contained in a file (for example, > if it has been replaced by a spare, or the error occurred during a > free of the bad block, and the bad block was in metadata, so it > held a reference to non-bad blocks). If it is replaced by a spare, I didn't have a problem. I just want to use the program to lookup files for which the error still is present (in my particular situation there was a read error on a file and I had to issue a write command to this block (with camcontrol) to have it replaced with a spare). If the bad block was in metadata, I'm screwed, but I think it is better to have a tool which solves a subset of my problems instead of not having a tool which solves a subset. > In any case, you are looking at a reverse lookup problem. But with my approach I didn't have to look at every allocated block (worst case) to find the file (like the backup approach), I have only to look at every allocated block which contains metadata. Bye, Alexander. -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 8:28:27 2001 Delivered-To: freebsd-fs@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id B32BF37B401 for ; Tue, 30 Oct 2001 08:28:25 -0800 (PST) Received: from dialup-209.245.128.217.dial1.sanjose1.level3.net ([209.245.128.217] helo=mindspring.com) by robin.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 15ybkR-0005y5-00; Tue, 30 Oct 2001 08:28:19 -0800 Message-ID: <3BDED556.92E9F028@mindspring.com> Date: Tue, 30 Oct 2001 08:29:10 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Leidinger Cc: bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? References: <200110301620.f9UGKiD07588@Magelan.Leidinger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alexander Leidinger wrote: > > In any case, you are looking at a reverse lookup problem. > > But with my approach I didn't have to look at every allocated block > (worst case) to find the file (like the backup approach), I have only to > look at every allocated block which contains metadata. You basically hit all the metadata unequally, which causes it to be more likely to fail in the future. 8-). You can run "fsck" in "scan mode", though I think that will no longer work with the demise of the difference between block and raw devices, with the added "protection" against multiple openenrs in the face of a mount. You could add a device/inode printer to the code where the error originated, though, pretty easily. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 10: 3:41 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BEE6237B409 for ; Tue, 30 Oct 2001 10:03:26 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA00020; Wed, 31 Oct 2001 05:03:07 +1100 Date: Wed, 31 Oct 2001 05:02:07 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alexander Leidinger Cc: , Subject: Re: physical block no -> name of file (FFS)? In-Reply-To: <200110301300.f9UD0KD05773@Magelan.Leidinger.net> Message-ID: <20011031044552.U4473-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 30 Oct 2001, Alexander Leidinger wrote: > On 30 Okt, Bruce Evans wrote: > > Just back up the files and note which ones can't be read. Better, compare > > them with a previous backup. > > Yes, this solves my problem (now that I know in which partition the bad > block is). > > But doesn't this need more resources than a dedicated program which only > traverses the metadata? On a busy system it may be worthwile to have > such a program (and I may be willing to write it). It is not possible to detect unreadable files by traversing only their metadata. Only unreadable metadata may be detected in this way. Every block in every file must be read to see if it can be, erm, read. It may be possible to find them all using dd on the disk device (with a block size of 1b so as not to miss any), but if there are a lot of them this probably won't be much faster than reading the files, especially if not all the bad blocks are in files, since the time for retrying the reads will dominate. > >> But thanks for the hint, I haven't thought at looking into fsck, will do > >> it later. > > > > fsck is not very useful for the original problem of finding files with > > bad blocks in them, since it only accesses metadata. > > And the sequence of blocks which holds the content of a given file > isn't included in this metadata? You still have to read them all to see if they are bad. The filesystem is likely to be better optimized for doing this than any simple program. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 11:20:29 2001 Delivered-To: freebsd-fs@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 1C0F537B407 for ; Tue, 30 Oct 2001 11:20:25 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA31957; Tue, 30 Oct 2001 11:17:49 -0800 (PST) Date: Tue, 30 Oct 2001 11:17:49 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: Alexander Leidinger , fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? In-Reply-To: <20011031044552.U4473-100000@delplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce, they already KNOW the bad block address. they want to find what file it is in... On Wed, 31 Oct 2001, Bruce Evans wrote: > On Tue, 30 Oct 2001, Alexander Leidinger wrote: > > > On 30 Okt, Bruce Evans wrote: > > > Just back up the files and note which ones can't be read. Better, compare > > > them with a previous backup. > > > > Yes, this solves my problem (now that I know in which partition the bad > > block is). > > > > But doesn't this need more resources than a dedicated program which only > > traverses the metadata? On a busy system it may be worthwile to have > > such a program (and I may be willing to write it). > > It is not possible to detect unreadable files by traversing only their > metadata. Only unreadable metadata may be detected in this way. Every > block in every file must be read to see if it can be, erm, read. It > may be possible to find them all using dd on the disk device (with a > block size of 1b so as not to miss any), but if there are a lot of > them this probably won't be much faster than reading the files, > especially if not all the bad blocks are in files, since the time for > retrying the reads will dominate. > > > >> But thanks for the hint, I haven't thought at looking into fsck, will do > > >> it later. > > > > > > fsck is not very useful for the original problem of finding files with > > > bad blocks in them, since it only accesses metadata. > > > > And the sequence of blocks which holds the content of a given file > > isn't included in this metadata? > > You still have to read them all to see if they are bad. The filesystem > is likely to be better optimized for doing this than any simple program. > > Bruce > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 12:23: 6 2001 Delivered-To: freebsd-fs@freebsd.org Received: from sbcs.cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by hub.freebsd.org (Postfix) with ESMTP id 4124937B403 for ; Tue, 30 Oct 2001 12:23:04 -0800 (PST) Received: from agora.fsl.cs.sunysb.edu (agora.fsl.cs.sunysb.edu [130.245.192.12]) by sbcs.cs.sunysb.edu (8.9.3/8.9.3) with ESMTP id PAA19972 for ; Tue, 30 Oct 2001 15:22:28 -0500 (EST) Received: (from ezk@localhost) by agora.fsl.cs.sunysb.edu (8.11.2/8.11.2) id f9UKN3o22392; Tue, 30 Oct 2001 15:23:03 -0500 Date: Tue, 30 Oct 2001 15:23:03 -0500 Message-Id: <200110302023.f9UKN3o22392@agora.fsl.cs.sunysb.edu> From: Erez Zadok To: fs@freebsd.org Subject: FreeNIX 2002 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I wanted to remind everyone that the deadline for submissions for the FreeNIX track of USENIX is coming up: November 12, 2001. You may submit either a complete paper, or a 2-5 page extended abstract or summary of your work to date. Submitting your work to FreeNIX is a great way of promoting your work and getting useful feedback from the world. It also provides visibility and useful exposure for projects like FreeBSD. The FreeNIX call for papers and directions on how to submit your paper can be found here: http://www.usenix.org/events/usenix02/cfp/freenix.html Feel free to email me if you need more info about FreeNIX or FreeNIX paper submissions. Cheers, Erez. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 30 20:51:55 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smail-103.hanmail.net (smail-103.hanmail.net [211.233.29.58]) by hub.freebsd.org (Postfix) with ESMTP id 929B337B403 for ; Tue, 30 Oct 2001 20:51:52 -0800 (PST) Received: from www15.hanmail.net (www15.hanmail.net [211.32.117.35]) by smail-103.hanmail.net (8.10.0/8.9.1) with ESMTP id f9V4nNN17112; Wed, 31 Oct 2001 13:49:23 +0900 Received: (from hanadmin@localhost) by www15.hanmail.net (8.10.0/8.9.1) id f9V4lGh27478 for ; Wed, 31 Oct 2001 13:47:16 +0900 (KST) X-Originating-IP: [129.254.122.173] From: "=?EUC-KR?B?wNPA57T2?=" Reply-To: "=?EUC-KR?B?wNPA57T2?=" Organization: =?EUC-KR?B?sOa6z7Trx9Cxsw==?= To: Subject: [Q]root file system mount(initialization) in booting time. X-Mailer: Daum Web Mailer 1.0 Date: Wed, 31 Oct 2001 13:47:16 +0900 (KST) Message-Id: <20011031134716.HM.E0000000002Ye4g@www15.hanmail.net> MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello. I have some question about filesystem initialization(namely, root filesystem mount) in FreeBSD 4.3. I can see the message that root file system is mounted. Then where is the routine that played this role.?? In VFS, I think 'vfsinit()' routine in 'vfs_init.c' file play that role. Right? (1) SI_SUB_VFS = 0x4000000, /* virtual file system*/ (2) SYSINIT(vfs, SI_SUB_VFS, SI_ORDER_FIRST, vfsinit, NULL); The sysinit_sub_id of VFS is defined in 'enum sysinit_sub_id {}' in 'kernel.h' file like (1). And VFS is ordered to initialize by 'SYSINIT()' macro in 'vfs_init.c' file like (2). If that's the case, How is the root file system(e.g. UFS/FFS) mounted in booting time? Is it like the VFS initialization..?? If so, where ? how? And then, next question is the order between VFS and root file system initialization. Is VFS initialization done before root filesystem mount in booting time? Or vice versa .? Please, answer me in detail if you possible. Thanks in advance. Bye, JaeDeok. =================================================================== 우리 인터넷, Daum http://www.daum.net 송금, 1/n청구, 회비걷기! 이메일 한통으로 해결한다 ☞ 메일뱅킹 http://mailbank.daum.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Oct 31 0:57: 7 2001 Delivered-To: freebsd-fs@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 7C01137B406 for ; Wed, 31 Oct 2001 00:57:00 -0800 (PST) Received: from dialup-209.247.138.195.dial1.sanjose1.level3.net ([209.247.138.195] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15yrB6-0003Ns-00; Wed, 31 Oct 2001 00:56:53 -0800 Message-ID: <3BDFBD07.85204EF3@mindspring.com> Date: Wed, 31 Oct 2001 00:57:43 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Bruce Evans , Alexander Leidinger , fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer wrote: > > Bruce, they already KNOW the bad block address. > they want to find what file it is in... That was my take on it, too... My caveat is that they might have seen the console message about the bad block during the free of the blocks it had references to, rather than the free of the bad block itself. That would put it outside a file. You kind of need to be able to ask the question "what file is this bad block in, or is it even in a file at all, any more?". This is harder than the orignal question, but is a likely corner case. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Oct 31 5:15: 3 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.wanlogistics.net (mail.wanlogistics.net [63.209.114.3]) by hub.freebsd.org (Postfix) with ESMTP id 04A1137B403 for ; Wed, 31 Oct 2001 05:15:00 -0800 (PST) Received: from bilver.wjv.com (spdsl-033.wanlogistics.net [63.209.115.33]) by mail.wanlogistics.net (8.9.3/8.9.3) with ESMTP id IAA41519; Wed, 31 Oct 2001 08:14:44 -0500 (EST) (envelope-from bill@wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.6/8.11.1) id f9VDEBR75908; Wed, 31 Oct 2001 08:14:11 -0500 (EST) (envelope-from bill) Date: Wed, 31 Oct 2001 08:14:11 -0500 From: Bill Vermillion To: Alexander Leidinger Cc: tlambert2@mindspring.com, bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? Message-ID: <20011031081410.A75720@wjv.com> Reply-To: bv@wjv.com References: <3BDECF33.7A280A2E@mindspring.com> <200110301620.f9UGKiD07588@Magelan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110301620.f9UGKiD07588@Magelan.Leidinger.net>; from Alexander@Leidinger.net on Tue, Oct 30, 2001 at 05:20:43PM +0100 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Oct 30, 2001 at 05:20:43PM +0100, Alexander Leidinger thus sprach: > On 30 Okt, Terry Lambert wrote: > > The problem is that you will have to exhaustively search 50% of > > all metadata to find a bad block that's contained in a file, and > > 100% of all metadata, if it's not contained in a file (for example, > > if it has been replaced by a spare, or the error occurred during a > > free of the bad block, and the bad block was in metadata, so it > > held a reference to non-bad blocks). > If it is replaced by a spare, I didn't have a problem. I just > want to use the program to lookup files for which the error still > is present (in my particular situation there was a read error on > a file and I had to issue a write command to this block (with > camcontrol) to have it replaced with a spare). Properly set up you should not have to do this. If you drive supports relocation and it is turned on, some drives don't have it turned on, then all of this should be transparent ----------------- AWRE (Auto Write Reallocation Enbld): 1 <*************** ARRE (Auto Read Reallocation Enbld): 1 <*************** TB (Transfer Block): 1 RC (Read Continuous): 0 EER (Enable Early Recovery): 0 PER (Post Error): 1 DTE (Disable Transfer on Error): 0 DCR (Disable Correction): 0 Read Retry Count: 41 Correction Span: 48 Head Offset Count: 0 Data Strobe Offset Count: 0 Write Retry Count: 24 Recovery Time Limit: 65535 The AWRE and ARRE at 1 say to reallocate on errors. Since you mentioned you used camcontrol to fix this then use the modepage of camcontrol to see this. The above is page 1. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Oct 31 8:21:54 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.wanlogistics.net (mail.wanlogistics.net [63.209.114.3]) by hub.freebsd.org (Postfix) with ESMTP id CD41637B401 for ; Wed, 31 Oct 2001 08:21:41 -0800 (PST) Received: from bilver.wjv.com (spdsl-033.wanlogistics.net [63.209.115.33]) by mail.wanlogistics.net (8.9.3/8.9.3) with ESMTP id LAA43132; Wed, 31 Oct 2001 11:21:33 -0500 (EST) (envelope-from bill@wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.11.6/8.11.1) id f9VGL1K82239; Wed, 31 Oct 2001 11:21:01 -0500 (EST) (envelope-from bill) Date: Wed, 31 Oct 2001 11:21:00 -0500 From: Bill Vermillion To: "Byan, Stephen" Cc: "'bv@wjv.com'" , Alexander Leidinger , tlambert2@mindspring.com, bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? Message-ID: <20011031112100.A82040@wjv.com> Reply-To: bv@wjv.com References: <378289F42B3FD51185AD0002B3302CF4091C7C@mmaexc01.mma.maxtor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <378289F42B3FD51185AD0002B3302CF4091C7C@mmaexc01.mma.maxtor.com>; from Stephen_Byan@Maxtor.com on Wed, Oct 31, 2001 at 07:09:25AM -0800 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Oct 31, 2001 at 07:09:25AM -0800, Byan, Stephen thus sprach: > > Bill Vermillion [mailto:bill@wjv.com] wrote: > > > If it is replaced by a spare, I didn't have a problem. I just > > > want to use the program to lookup files for which the error still > > > is present (in my particular situation there was a read error on > > > a file and I had to issue a write command to this block (with > > > camcontrol) to have it replaced with a spare). > > > > Properly set up you should not have to do this. > > If you drive supports relocation and it is turned on, some drives > > don't have it turned on, then all of this should be transparent > > > > ----------------- > > AWRE (Auto Write Reallocation Enbld): 1 <*************** > > ARRE (Auto Read Reallocation Enbld): 1 <*************** > > TB (Transfer Block): 1 > > RC (Read Continuous): 0 > > EER (Enable Early Recovery): 0 > > PER (Post Error): 1 > > DTE (Disable Transfer on Error): 0 > > DCR (Disable Correction): 0 > > Read Retry Count: 41 > > Correction Span: 48 > > Head Offset Count: 0 > > Data Strobe Offset Count: 0 > > Write Retry Count: 24 > > Recovery Time Limit: 65535 > > > > The AWRE and ARRE at 1 say to reallocate on errors. Since you > > mentioned you used camcontrol to fix this then use the modepage > > of camcontrol to see this. The above is page 1. > Setting ARRE (Auto Read Reallocation Enbld) only enables > reallocation on a recovered read error. If the read error is > unrecoverable, then the drive will not reallocate the LBA. Section > 7.1.3.7 of the ANSI SCSI-3 Block Commands (SBC) standard says > "[t]he automatic reallocation shall then be performaned only if > the device server successfully recovers the data". > On an unrecovered read error, simply writing the block is probably > not be enough to cause a spare sector to be reassigned to the LBA, > even if AWRE (Auto Write Reallocation Enbld) is set. The drive > does not read the sector before overwriting it, so it is unlikely > that the write will encounter the same fault that generated the > uncorrectable read error. > In general you have two options for "repairing" an uncorrectable > read error. Well I've only had one uncorrectable error. That was on a rack mounted SGI server - and someone had NOT bolted the rack down and someone tripped and the rack moved. > First, you can simply overwrite the sector with new data, without > reassigning the LBA to a spare sector, in the expectation that > the fault was not a media defect, but rather an off-track write. > Second, you can issue a REASSIGN BLOCK command, to cause the LBA > to be reassigned to a spare sector, followed by a WRITE. Without > the WRITE, the contents of the reassigned LBA are unspecified, and > reading that LBA may result in an unrecoverable read error. Nothing I've used falls in that area - all Unix systems an all SCSI. > Theoretically, all media faults have been mapped out during the > drive manufacturing process, and there should be no "grown" > defects, so in most cases the source of the uncorrectable read > error is data that was written off-track, or interference from > data for a neighboring track that was written off-track. Well I've had grown defects in the past - none in the EIDE arena but in the SCSI world. At times I think I've been playing with these beasts too long. > In real life, some media defects may escape detection during the > factory media scan. In this case, reassigning the LBA to a spare > sector is the correct recovery action. And I've never had anything fail to do that, except the SGI and the xfs file system doesn't give you a lot of lee-way in correcting those. The only possible action there, and is documented as such, is to remake the file system. I'd use the low-level format routines, where you could set the way the buffers were allocated, etc, and manipulate drive as the lowest level. I'd basically re-QC the drive to remap all areas. > Another possibility is that the media defect is truly a grown > defect, i.e. a result of a head crash or other particulate > contamination in the drive. In this case, expect a growing cascade > of hard read errors over time. The correct recovery action is to > backup what data is readable, replace the drive, and restore from > your backup media. Yup. I've seen that. But guess what - in most cases I've not replaced the drive. There is a old believe that one failure is just a pre-cursor to many. Much of this started in the days of coated media and often a bit could flake off. And this flake could get under heads or elsewhere, and it could just cascade. With the advent of plated media this is not neccesarily true. Often a bad area is nothing more than a marginal area in the coating that did not show up in the first place and was not mapped out during manufacture. There was also the old adage about reformatting your drive to 'refresh' the media - but I think that was more attributeable to the wear associated in the days of drives with stepper motors where the mechanisms could wear and track alignment could occur and a reformat cured that. Then the dedicated servo took over, and with the embedded servo that's something we don't have to worry about any more, at least not as I see it. > Speaking for myself, not Maxtor, I recommend the following error > handling policy: > 1) on the first occurrance of an uncorrectable read error for an LBA, > rewrite the block without reassigning the LBA to a spare. > 2) on the second occurrance of an uncorrectable read error for an LBA, > reassign the LBA to a spare and rewrite the block. > 3) if a high frequency of uncorrectable read errors on varying > LBA's occurs, alert the operator to take immediate preventive > maintenance action, by initiating a backup, drive replacement, and > restore. The SMART failure prediction algorithms in the drive may > be sufficient to detect and report this case, but I'm not familiar > enough with them to state that with certainty. Well in "The Goode Olde Dayze" :-) I got a Maxtor ESDI - this was when the battle was between ESDI and SCSI and no one was sure what would survive - I wound up with an Maxtor at a reasonable price - $1300 for 600+MB - about $400 off because the bad track list was over 300 - the maxium acceptable for a new drive. I put it in service. Formatted with altnerate sector replacement, so that if a sector went bad ECC kicked in, reread the data, reformatted the track with the bad sector as sector 0 [thus unseeable] rewrote the data an continued on. If I got more than one bad sector the track was reallocated. The system was in a desk side tower - and it did get bumped now and then :-(. Sometimes no problem - other times you would see some re-mapping. This was a very active system as a news-node. After a few years and it was still going I decided to see how long it would go. At about the 6th year it ran out of free tracks to reallocate. At the end of seven years, 2 months and 2 weeks the system failed, and it was most probably the controller as floppy access - also on the controller - had gotten bad too. I see re-write/re-map on some SCSI drives too [not Maxtor/Quantum] and they are due for replacement soon - as their size and age [running 24x7 for five years] make replacement recommended. > If you happen to have a recent Maxtor (aka Quantum) SCSI drive, > if you set the Reallocate Uncorrected Errors bit (byte 2 bit 4) > on the Maxtor-unique mode page (mode page 39h), you will get > approximately the above algorithm. From the Atlas 10K III Product > Manual, Publication Number 81-126196-01: Thanks for that information. I recall that a very long time ago the number of bits for ECC was settable somewhere deep down inside the drive - is this the case anymore. I'm just asking this out of curiousity. > "When this field = 1, a block that encounters an uncorrectable > read error will be marked for pending reallocation. The block in > error remains "as is" for a possible recovery on a future access. > If a subsequent successful read or write (with readback / compare) > occur, the pending reallocation will be deferred. However, it > will be "remembered" that an unrecoverable read occurred at > one time, and if a second unrecoverable read occurs, the block > will be reallocated on the next successful access. Also, if a > subsequent unsuccessful write occurs on a block marked for pending > reallocation, the block will be reallocated." Now that is a much better approach than the old way. I'm constantly amazed by the progress the HD industry is making. > The "remembering" is persistent across power-cycles. You'll need > to re-write the block to remove the uncorrectable read error > - when the drive reallocates an uncorrectable read error, it > marks the new sector as containing bad data, and will return an > uncorrectable read error until that LBA is overwritten. Thanks for the details. As I say I'd never had any problems with re-writing anything automagically except the reall hard error on the SGI. That required going to the low-level format routine. Now that was interesting as the right move in the wrong place could mean that drive would not work again until it went back to it's manufacturer. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Oct 31 9:52:12 2001 Delivered-To: freebsd-fs@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id AE83737B401 for ; Wed, 31 Oct 2001 09:52:08 -0800 (PST) Received: from dialup-209.247.137.200.dial1.sanjose1.level3.net ([209.247.137.200] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15yzWv-0002vC-00; Wed, 31 Oct 2001 09:51:58 -0800 Message-ID: <3BE03A6B.33F1D15B@mindspring.com> Date: Wed, 31 Oct 2001 09:52:43 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Byan, Stephen" Cc: "'bv@wjv.com'" , Alexander Leidinger , bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? References: <378289F42B3FD51185AD0002B3302CF4091C7C@mmaexc01.mma.maxtor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org VERY nice article, Stephan! We should capture this somewhere as a reference work (like the handbook, as oppose to just the list archives). Two comments: 1) You can _want_ to disable automatic relocation; this is most common when you set up spindle sync in order to make virtually taller platter stacks. In early FreeBSD, Rod Grimes did this for SCSI. "Byan, Stephen" wrote: > Theoretically, all media faults have been mapped out during the drive > manufacturing process, and there should be no "grown" defects, so in most > cases the source of the uncorrectable read error is data that was written > off-track, or interference from data for a neighboring track that was > written off-track. (Note that both of these are rare occurances, and that > drives take special care to verify that the head is in the right place > before and after writing, and will retry the write if the head moved > off-track during the write. But in rare cases, external shock or vibration > could force an off-track write. Don't kick the mainframe equipments :-) In > this case, rewriting the sector without reassigning the LBA to a spare is > the correct recovery action. 2) The most common case I have seen for this is "multimedia" drives. The reason for this is that it is (was?) very common for companies building "multimedia" drives to intentionally disable thermal recalibration, since this could result in a "hiccup" when recording from a live source. This is, IMO, the most common cause of off-track reads or writes. One of the first things I used to do once these drives became cheaper than other "non-multimedia" drives was to turn the recalibration back on. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Nov 3 17:42:49 2001 Delivered-To: freebsd-fs@freebsd.org Received: from rowan.netcom.ubc.ca (rowan.netcom.ubc.ca [137.82.1.15]) by hub.freebsd.org (Postfix) with ESMTP id AB45A37B409; Sat, 3 Nov 2001 17:42:14 -0800 (PST) Received: from cal.cstudies.ubc.ca (cal.cstudies.ubc.ca [142.103.75.169]) by rowan.netcom.ubc.ca (8.11.2/8.11.2) with ESMTP id fA41gDA02043; Sat, 3 Nov 2001 17:42:13 -0800 (PST) Received: from _[134.88.19.211]_by (da001d1065.lax-ca.osd.concentric.net [64.0.148.44]) by cal.cstudies.ubc.ca (8.8.8+Sun/8.8.8) with SMTP id RAA14511; Sat, 3 Nov 2001 17:42:07 -0800 (PST) From: poetoflove01@excite.com Message-Id: <200111040142.RAA14511@cal.cstudies.ubc.ca> Received: from [107.109.54.42] by _[134.88.19.211]_by with SMTP id A98C12E1 Sat, 3 Nov 2001 17:29:10 PDT Subject: Romance starts here... Reply-To: caridreams411@yahoo.com Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Date: Sat, 3 Nov 2001 17:46:27 To: undisclosed-recipients:; Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org

Take control of your social life and join our community.
We offer a great way for busy, interesting and successful people to meet
each other in our safe, secure and anonymous environment.

Life should be wonderful. Find someone extraordinary to share your adventures with.
STOP waiting. START living.

GO meet Somebody!

CLICK HERE 


If you have received this message in error click here to be removed

 


To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message