From owner-freebsd-questions@FreeBSD.ORG Mon Mar 4 09:17:00 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BBBED363 for ; Mon, 4 Mar 2013 09:17:00 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6267DD for ; Mon, 4 Mar 2013 09:10:37 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c13so3796832eek.0 for ; Mon, 04 Mar 2013 01:10:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=hxRRR1LjIIWZerst7/7RbF/XvV9tkS6+I7VcSNSHrzA=; b=BQUhgOH4Rjdcf7Vuqljebc+At2uf4LJX+7QHqtRitAO4/SJvZLGjyl4Uc5/d87RHvk 0eTmBVxylNWna6Q2iHIYkFrsmsm55YR4Najuu1PcCi0esaPBmMNAKPUKjFHrOqnzF5Qx plvuMR8yEDMuWla3EEYJRaTCZn5CfNI3INz9eFfjgJREFoGGEmr45e8bmctLZNpQzFk4 P4e7RlvKsi0nyT3vM2qox31wzd9Q5rHy9w6jxGNfWbYO/FrrWUsYVXniJRK+xYB4mJr9 qS84h+7lZwF3ORht0U18WH1Wd2E2w7B6oqk/+7zDnJm8LVEdlBa/eKv+dq5W8ADX20+k cfRA== X-Received: by 10.14.1.130 with SMTP id 2mr56744687eed.15.1362388230657; Mon, 04 Mar 2013 01:10:30 -0800 (PST) Received: from [10.187.242.156] ([92.90.16.79]) by mx.google.com with ESMTPS id f47sm30876601eep.13.2013.03.04.01.10.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 01:10:24 -0800 (PST) References: <20130304013608.7981e8a9.freebsd@edvax.de> Mime-Version: 1.0 (1.0) In-Reply-To: <20130304013608.7981e8a9.freebsd@edvax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8402144E-5ECB-44E9-99FB-0258C855FE7B@my.gd> X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: Grepping though a disk Date: Mon, 4 Mar 2013 10:09:50 +0100 To: Polytropon X-Gm-Message-State: ALoCoQnGXA8/BCxB3sbgwcwvBP4TlUMS1EKCiWZwDpTXfUgMw8dXWKEwYbk8ec+9NIurWaNty0Q5 Cc: FreeBSD Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 09:17:00 -0000 On 4 Mar 2013, at 01:36, Polytropon wrote: > Due to a fsck file system repair I lost the content of a file > I consider important, but it hasn't been backed up yet. The > file name is still present, but no blocks are associated > (file size is zero). I hope the data blocks (which are now > probably marked "unused") are still intact, so I thought > I'd search for them because I can remember specific text > that should have been in that file. >=20 > As I don't need any fancy stuff like a progress bar, I > decided to write a simple command, and I quickly got > something up and running which I _assume_ will do what > I need. >=20 > This is the command I've been running interactively in bash: >=20 > $ N=3D0; while true; do echo "${N}"; dd if=3D/dev/ad6 of=3D/dev/stdout b= s=3D10240 count=3D1 skip=3D${N} 2>/dev/null | grep ""; if [ $? -eq 0= ]; then break; fi; N=3D`expr ${N} + 1`; done >=20 > To make it look a bit better and illustrate the simple > logic behind my idea: >=20 > N=3D0 > while true; do > echo "${N}" > dd if=3D/dev/ad6 of=3D/dev/stdout bs=3D10240 count=3D1 skip=3D${N} \= > 2>/dev/null | grep "" > if [ $? -eq 0 ]; then > break > fi > N=3D`expr ${N} + 1` > done >=20 > Here refers to the text. It's only a small, but > very distinctive portion. I'm searching in blocks of 10 kB > so it's easier to continue in case something has been found. > I plan to output the resulting "block" (it's not a real disk > block, I know, it's simply a unit of 10 kB disk space) and > maybe the previous and next one (in case the file, the _real_ > block containing the data, has been split across more than > one of those units. I will then clean the "garbage" (maybe > from other files) because I can easily determine the beginning > and the end of the file. >=20 > Needless to say, it's a _text_ file. >=20 > I understand that grep operates on text files, but it will > also happily return 0 if the text to search for will appear > in a binary file, and possibly return the whole file as a > search result (in case there are no newlines in it). >=20 > My questions: >=20 > 1. Is this the proper way of stupidly searching a disk? >=20 > 2. Is the block size (bs=3D parameter to dd) good, or should > I use a different value for better performance? >=20 > 3. Is there a program known that already implements the > functionality I need in terms of data recovery? >=20 > Results so far: >=20 > The disk in question is a 1 TB SATA disk. The command has > been running for more than 12 hours now and returned one > false-positive result, so basically it seems to work, but > maybe I can do better? I can always continue search by > adding 1 to ${N}, set it as start value, and re-run the > command. >=20 > Any suggestion is welcome! >=20 >=20 Hey that's actually a pretty creative way of doing things ;) Just to make sure, you've stopped daemons and all the stuff that could poten= tially write to the drive and nuke your blocks right ?