Michael Roedig wrote:
I thought that the utility at:
had the ability to search for filesystems. I'm not seeing it in the
fsrd.txt doc file, though.
Ah... searching google groups reveals the answer:
fsrd -f HTFS [device] search -vh -S
This gets you a starting point; it will still be a lot of hard work to
actually reconstruct the system.
It will likely return a lot of false matches as well as the true
filesystems you're looking for. You can filter the output somewhat by
knowing that unless you manually created the filesystems, by default
they are created with one inode per 4 blocks. `fsrd` displays
filesystem parameters named FSIZE and ISIZE. FSIZE is the size of the
filesystem in blocks; ISIZE is the size of the inode table in blocks.
EAFS filesystems contain 16 inodes per block, so an EAFS with the
default inode ratio will have FSIZE:ISIZE of about 64. HTFS has 8
inodes per block, so its FSIZE:ISIZE will be about 32.
You may see matches of filesystem types: XENIX, S51K, ES51K, AFS, EAFS,
HTFS. Unless you had been doing something rather unusual, the only
types that will represent true matches are EAFS and HTFS.
Even after filtering according to these hints, I get many false matches
on my desktop machine. They appear to be duplicates of the real
superblocks of the filesystems.
The offsets you get will be relative to the device you specified. Even
if your partition table is intact, the offsets within it won't reflect
exactly what you would put in the divvy table. That's because `divvy`
divides the partition starting at the first whole cylinder boundary
after the partition's `badtrk` alias tracks, or (in your case)
`scsibadblk` alias blocks. `fsrd` displays offsets relative to the
start of the partition, you have to figure out the offset. If the size
of the bad track/block alias area is right (which typically it will be),
this is approximately the same as the number reported by `divvy` as
"blocks reserved for the system".
You can eliminate a lot of the false matches -- maybe all of them -- by
visualizing how they overlap. Once you've found one good filesystem,
you can be pretty sure no other good filesystem overlaps it. So any
other superblocks found by `fsrd` within that filesystem's boundaries
are probably false.
One further obstruction: `fsrd` doesn't appear to have been modified for
searching (and the failure isn't obviously due to that -- it just
reports something like "read(): 24576/32768"). Two ways to get past
that: modify `fsrd` to support >2GB devices, or cheat. Cheat by using
`divvy` to divide the partition into a bunch of 2GB divisions; search
them with `fsrd`; calculate the true offsets yourself.
`fsrd` is a useful utility which unfortunately hasn't been maintained in
years (and all of its internal doentation is in Czech). It would be
good if someone picked up its maintenance...
Before `fsrd`, I did this sort of recovery a couple of times with much
simpler procedures. This might work for you:
Run `divvy` on the partition. Assume that a filesystem exists starting
a divvy offset 0. So make one that starts there and ends at the end of
the partition. Give it a name. Make sure the "New FS" column says "no"
(that is, do not tell `divvy` to "c[reate]" a filesystem there). Quit,
install, then run `divvy` again. If your guess was right, it will fill
in a sensible filesystem type. Quit. Run `df -vk /dev/name`, using the
name you gave it. This will tell you how big the superblock claims the
filesystem is. Now go back into `divvy` and set the end of that
division to match. (If `df` said 100000 blocks, end should be start +
99999.) Then start another division on the next open block. Repeat
until you've found everything.
This falls down if it's a root disk. A root disk will typically have a
swap area immediately after the small boot division. Swap isn't a
filesystem, so it won't have an internal hint as to its size. But you
do know that it must be 4GB or smaller. `fsrd` might be helpful in
getting across a swap-induced gap even if you don't use it for the more