Professional Web Applications Themes

HTFS Filesystem - SCO

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...

  1. #1

    Default HTFS Filesystem

    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 Guest

  2. #2

    Default Re: HTFS Filesystem

    Michael Roedig wrote:
     

    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 
    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
    general search.
     
    Bela Guest

  3. #3

    Default Re: HTFS Filesystem

    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" <com> wrote in message
    news:com... [/ref]
    create [/ref]
    is 
    >
    > 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 
    > 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...
    >
    >[/ref]
    ================================================== ==========================
    = [/ref]


    Michael Guest

  4. #4

    Default Re: HTFS Filesystem

    Michael Roedig wrote:
     

    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 Guest

  5. #5

    Default Re: HTFS Filesystem

    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" <com> wrote in message
    news:com... [/ref]
    so I [/ref]
    that, [/ref]
    to [/ref]
    disk [/ref]

    >
    > 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.
    > [/ref]


    Michael Guest

  6. #6

    Default Re: HTFS Filesystem


    "Michael Roedig" <net> wrote in message
    news:3f859d05$0$52147$fuse.net... 
    block 
    who 

    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


    Bob Guest

Similar Threads

  1. Filesystem io
    By Peter in forum AIX
    Replies: 3
    Last Post: January 27th, 12:42 PM
  2. Filesystem hang
    By Ervins in forum AIX
    Replies: 2
    Last Post: January 19th, 01:44 PM
  3. SCO Filesystem
    By c3q8 in forum SCO
    Replies: 5
    Last Post: August 8th, 09:58 AM
  4. filesystem help
    By Bela Lubkin in forum SCO
    Replies: 0
    Last Post: July 29th, 08:41 AM
  5. "HTFS: No space on dev hd (1/32)"
    By person@24-119-32-27.cpe.cableone.net in forum SCO
    Replies: 0
    Last Post: July 18th, 01:05 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139