From owner-freebsd-current@FreeBSD.ORG Sun Mar 14 17:48:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46DF9106564A for ; Sun, 14 Mar 2010 17:48:09 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id D17CD8FC1D for ; Sun, 14 Mar 2010 17:48:08 +0000 (UTC) Received: from [195.4.92.26] (helo=16.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1Nqrv5-0006iJ-AP; Sun, 14 Mar 2010 18:48:07 +0100 Received: from p57ae2388.dip0.t-ipconnect.de ([87.174.35.136]:61638 helo=ernst.jennejohn.org) by 16.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1Nqrv5-0004Dj-23; Sun, 14 Mar 2010 18:48:07 +0100 Date: Sun, 14 Mar 2010 18:48:06 +0100 From: Gary Jennejohn To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20100314184806.3eddf33b@ernst.jennejohn.org> In-Reply-To: <4B9D0C65.7000809@quip.cz> References: <20100308102918.GA5485@localhost> <4B94DDC8.5080008@quip.cz> <20100308115052.GA31896@office.redwerk.com> <4B94FBA6.5090107@quip.cz> <861vfq995i.fsf@ds4.des.no> <4B9BF957.4060507@quip.cz> <86eijn3of2.fsf@ds4.des.no> <4B9CB287.9080205@quip.cz> <20100314123859.47664ace@ernst.jennejohn.org> <4B9D0C65.7000809@quip.cz> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: A tool for remapping bad sectors in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 17:48:09 -0000 On Sun, 14 Mar 2010 17:18:45 +0100 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Gary Jennejohn wrote: > > On Sun, 14 Mar 2010 10:55:19 +0100 > > Miroslav Lachman<000.fbsd@quip.cz> wrote: > > > > [big snip] > >> fsdb (inum: 3)> blocks > >> Blocks for inode 3: > >> Direct blocks: > >> 3001 (1 frag) > >> > >> fsdb (inum: 3)> findblk 3001 > >> fsdb (inum: 3)> > >> > >> ^^^^^^^^ findblk did not returned inode 3! > >> > > > > This is almost guaranteed to be a file system block and not > > a disk block. > > Do you mean the number 3001? > I am sorry for my ignorance, but it is not clear to me from fsdb manpage > what "blocks" means FS block and what disk block. > > And how can I use (calculate with) this numbers? > > How can I get the right number to pass to findlbk command (in the > example above) to give me back the inode 3? > > If FS block is 16384 bytes, then it means 16384/512 = 32 disk blocks per > FS block. > > If 3001 is FS block, then it means 3001*32 = 96032 disk block number. Am > I right? > > fsdb (inum: 3)> findblk 96032 > fsdb (inum: 3)> > > Again - findblk did not returned inode 3. > > So what is the exact formula to get the right findblk number and then > right inode number as result of findblk command? > > I am still lost in terms (words) and numbers :( > Well, it's pretty hairy. Looking at findblk() it does this to go from disk block to file system block (this is greatly simplified) file_system_blockno = disk_blockno >> fs_fsbtodb; So conversely, you'd do disk_blockno = file_system_blockno << fs_fsbtodb. You can get this information using "ffsinfo -l 0x001 -o some_file /dev/ataXY" (using ahci) and grep'ing for fsbtodb in some_file. The 0x001 means to only dump the first super block. I looked at a file system which has default 16kB file system blocks and fsbtodb is 2 ==> *multiply file_system_block by 4 not 32*. This is probably because it's a multiple of a 4kB block, which is the smallest usable file system block size AFAIK. BTW looking at the code leads me to conclude that fsdb will not print out anything if the disk block you're trying to find has bever been allocated to an inode ==> unused disk block, safe to overwrite. This assumes that you calculated the disk block correctly. --- Gary Jennejohn