Grepping though a disk

[Polytropon]

On Mon, 04 Mar 2013 04:15:48 -0600, Joshua Isom wrote:
> I'd call bs= essential for speed.  Any copying will be faster with 
> something higher.

I thought about that. Narrowing down _if_ something has
found is easy, e. g. when the positive 1 MB unit is dd'ed
to a file, further work can easily be applied.



> Also, there's the possibility, very annoying, that 
> your search string overlaps a place where you read.  I'd probably check 
> 1M blocks, but advance maybe 950k each time.

I also thought about that, that's why the distinctive
phrase I'm searching for is less than 10 characters long.
Still it's possible that it appears "across" a boundary
of units, no matter how big or small I select bs=.

But I don't know how to do this. From reading "man dd"
my impression (consistent with my experience) is that
the option skip= operates in units of bs= size, so I'm
not sure how to compose a command that reads units of
1 MB, but skips in units of 950 kB. Maybe some parts of
my memory have also been marked "unused" by fsck. :-)



> Make sure you're reading 
> from block offsets for maximum speed.

How do I do that? The disk is a normal HDD which has been
initialized with "newfs -U" and no further options.

	ad6: 953869MB <Hitachi HDS721010DLE630 MS2OA5R0>
	at ata3-master UDMA100 SATA 1.5Gb/s

The file system spans the whole disk.



> I know disk editors exist, I 
> remember using one on Mac OS 8.6 for find a lost file.  That was back on 
> a 6 gig hard drive.

Ha, I've done stuff like that on DOS with "important business
data" many years ago, using the "Norton Disk Doctor" (NDD.EXE)
when Norton (today: Symantec) wasn't yet synonymous for "The
Yellow Plague". This program actually was quite cool, and you
could search for things, manipulate disks on several levels
(files, file system and below). I had even rewritten an entire
partition table from scratch, memory and handheld calculator
after an OS/2 installation went crazy. :-)



> Depending on the file size, you could open the disk in vi and just 
> search from there, or just run strings on the disk and pipe it to vi.

You mean like "strings /dev/ad6 | something", without dd? That
would give me _no_ progress indicator (with my initial approach
I have increasing numbers at least), but I doubt I can load a
1 TB partition in a vi session with only 2 GB RAM in the machine.

If I try "strings /dev/ad6" I get a warning: "strings: Warning:
'/dev/ad6' is not an ordinary file". True. But this opens a
useful use of cat: "cat /dev/ad6 | strings". (Interesting idea,
I will investigate this further.)

The file size of the file I'm searching for is less than 10 kB.
It's a relatively small text file which got some subsequent
additions in the last days, but hasn't been part of the backup
job yet. I can only remember parts of those additions, because
as I said my brain is not good with computer. :-)

Or do you think of something different? If yes, please explain.
The urge to learn is strong when something went wrong. :-)


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...