Date: Tue, 30 Oct 2001 17:20:43 +0100 (CET) From: Alexander Leidinger <Alexander@Leidinger.net> To: tlambert2@mindspring.com Cc: bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? Message-ID: <200110301620.f9UGKiD07588@Magelan.Leidinger.net> In-Reply-To: <3BDECF33.7A280A2E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110301620.f9UGKiD07588>