I have a SCSI disk that lost it's division table. I need to tell divvy
where the starting and ending blocks were for my filesystems so I can create
devices and remount. If I scan the disk with a disk scanning utility, is
there a string of characters which would indicate the beginning of a
filesystem?

Thanks,
Mike

Michael Roedig wrote:

> I have a SCSI disk that lost it's division table. I need to tell divvy
> where the starting and ending blocks were for my filesystems so I can create
> devices and remount. If I scan the disk with a disk scanning utility, is
> there a string of characters which would indicate the beginning of a
> filesystem?

I thought that the utility at:

ftp://ftp.armory.com/pub/user/rts/fsrd

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
>2GB device support. It fails at the 2GB point within the device you're
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 documentation 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
general search.

>Bela<

Thanks for all the info Bela, I will try this. This is/was a root disk so I
do have to account for the swap and boot partitions. I was thinking that,
since I took the default swap and boot partition sizes, I should be able to
estimate where the original divisions were based on system memory and disk
size. I was afraid to try b/c my support at SCO said if I recreated a
division table (saying no to new FS) divvy would still wipe out my data. I
really didn't believe them, but I figured they know more that I.
Maybe...maybe not.

"Bela Lubkin" <belal@sco.com> wrote in message
news:20031008100244.GK714@sco.com...
> Michael Roedig wrote:
>
> > I have a SCSI disk that lost it's division table. I need to tell divvy
> > where the starting and ending blocks were for my filesystems so I can
create
> > devices and remount. If I scan the disk with a disk scanning utility,
is
> > there a string of characters which would indicate the beginning of a
> > filesystem?
>
> I thought that the utility at:
>
> ftp://ftp.armory.com/pub/user/rts/fsrd
>
> 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
> >2GB device support. It fails at the 2GB point within the device you're
> 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 documentation 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
> general search.
>
> >Bela<

Michael Roedig wrote:

> Thanks for all the info Bela, I will try this. This is/was a root disk so I
> do have to account for the swap and boot partitions. I was thinking that,
> since I took the default swap and boot partition sizes, I should be able to
> estimate where the original divisions were based on system memory and disk
> size. I was afraid to try b/c my support at SCO said if I recreated a
> division table (saying no to new FS) divvy would still wipe out my data. I
> really didn't believe them, but I figured they know more that I.
> Maybe...maybe not.

There is one fairly irrevokable thing that happens if you create a new
divvy table on a partition (with `divvy -m` or `divvy -i`): the existing
badtrk or scsibadblk table is wiped out. If the previous partition had
been scanned with (in your case) `scsibadblk`, bad blocks set aside,
then this information will be lost. Which would make a bad hash of any
data on the partition.

Fortunately, modern drives hide bad blocks from the OS. I think it is
unlikely that your SCSI drive has an active OS-managed back block table.


Also, the OS-managed bad track/block table, and its alias tracks/blocks,
follow immediately after the divvy table on the disk. So whatever the
incident that killed its divvy table, it quite likely also destroyed the
alias block information -- even if it was important, it's probably
already lost.

>Bela<

The drive was only a few years old so the OS was not managing the bad block
table. I used the fsd utility with great success. Since I was the one who
created the filesystems, I recognized familar numbers and was able to line
up my filesystems on the first try. Bela, you really helped me out of a
bind with your expertise. You saved me a lot of time and possibly money.

I am very grateful!
Mike

"Bela Lubkin" <belal@sco.com> wrote in message
news:20031008202141.GL714@sco.com...
> Michael Roedig wrote:
>
> > Thanks for all the info Bela, I will try this. This is/was a root disk
so I
> > do have to account for the swap and boot partitions. I was thinking
that,
> > since I took the default swap and boot partition sizes, I should be able
to
> > estimate where the original divisions were based on system memory and
disk
> > size. I was afraid to try b/c my support at SCO said if I recreated a
> > division table (saying no to new FS) divvy would still wipe out my data.
I
> > really didn't believe them, but I figured they know more that I.
> > Maybe...maybe not.
>
> There is one fairly irrevokable thing that happens if you create a new
> divvy table on a partition (with `divvy -m` or `divvy -i`): the existing
> badtrk or scsibadblk table is wiped out. If the previous partition had
> been scanned with (in your case) `scsibadblk`, bad blocks set aside,
> then this information will be lost. Which would make a bad hash of any
> data on the partition.
>
> Fortunately, modern drives hide bad blocks from the OS. I think it is
> unlikely that your SCSI drive has an active OS-managed back block table.
>
>
> Also, the OS-managed bad track/block table, and its alias tracks/blocks,
> follow immediately after the divvy table on the disk. So whatever the
> incident that killed its divvy table, it quite likely also destroyed the
> alias block information -- even if it was important, it's probably
> already lost.
>
> >Bela<

"Michael Roedig" <michael.roedig@fuse.net> wrote in message
news:3f859d05$0$52147$a0465688@nnrp.fuse.net...
> The drive was only a few years old so the OS was not managing the bad
block
> table. I used the fsd utility with great success. Since I was the one
who
> created the filesystems, I recognized familar numbers and was able to line
> up my filesystems on the first try. Bela, you really helped me out of a
> bind with your expertise. You saved me a lot of time and possibly money.
>
> I am very grateful!
> Mike

Even though I may be beating a dead horse, I've got to ask you this:

Do you have a viable backup procedure for this system?
If not, do you plan to get one real soon now?

Hardware failures are a fact of life, and using one of the oft-mentioned
"supertar" products obviates the need to ever have to use a utility like
fsd (you'd simply replace the defective hardware and restore from your
most recent backup(s)). The only exception to this rule is if you had to
recover critical information created since your last backup. And even
in this case, recovery utilities like RecoverEdge provide you with a
hard copy of the divvy table & partition table when you create the
recovery media.

You spent almost 40 hours dealing with this problem. You could have
been up and running in less than an hour with a supertar.

Bob