Grepping though a disk
freebsd at edvax.de
Mon Mar 4 11:15:26 UTC 2013
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. :-)
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions