Shadow set problem finally solved - VMS

This is a discussion on Shadow set problem finally solved - VMS ; In article , tadamsmar writes: >On Mar 13, 12:07=A0pm, VAXman- @SendSpamHere.ORG wrote: >> In article >com>, tadamsmar writes: >> >> >{...snip...} >> >> >Opps, not quite there. =A0It ran clean on the single disk. =A0But when I >> >add the ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: Shadow set problem finally solved

  1. Re: Shadow set problem finally solved

    In article <1f5f98b1-5433-4687-953d-c3ac4a3e020f@m44g2000hsc.googlegroups.com>, tadamsmar writes:
    >On Mar 13, 12:07=A0pm, VAXman- @SendSpamHere.ORG wrote:
    >> In article
    >com>, tadamsmar writes:
    >>
    >> >{...snip...}

    >>
    >> >Opps, not quite there. =A0It ran clean on the single disk. =A0But when I
    >> >add the other disk to the shadowset it reported the 4 blocks with
    >> >errors. =A0VMS does not want to give these up without a fight.

    >>
    >> >I'm am going to init/erase that disk.

    >>
    >> What happens if you shadow and mount an init'd disk (i.e. nothing on it)?


    Aren't you init'ing and then restoring your backup to it?

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  2. Re: Shadow set problem finally solved

    On Mar 13, 2:04*pm, VAXman- @SendSpamHere.ORG wrote:
    > In article <1f5f98b1-5433-4687-953d-c3ac4a3e0...@m44g2000hsc.googlegroups.com>, tadamsmar writes:
    >
    > >On Mar 13, 12:07=A0pm, VAXman- *@SendSpamHere.ORG wrote:
    > >> In article
    > >com>, tadamsmar writes:

    >
    > >> >{...snip...}

    >
    > >> >Opps, not quite there. =A0It ran clean on the single disk. =A0But when I
    > >> >add the other disk to the shadowset it reported the 4 blocks with
    > >> >errors. =A0VMS does not want to give these up without a fight.

    >
    > >> >I'm am going to init/erase that disk.

    >
    > >> What happens if you shadow and mount an init'd disk (i.e. nothing on it)?

    >
    > Aren't you init'ing and then restoring your backup to it?


    I did an init/erase, and restored the backup. But for the second
    disk, I did a init/erase and just put into the shadow set. I tried
    putting the second disk in the shadowset without an init/erase but it
    still had the 4 bad blocks, so I did and init/erase on it.

    I never tried a plain old init.

    I still don't quite understand what you are asking, or why.

    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker * VAXman(at)TMESIS(dot)COM
    >
    > * "Well my son, life is like a beanstalk, isn't it?"
    >
    > http://tmesis.com/drat.html



  3. Re: Shadow set problem finally solved

    In article <444fde84-b0dc-4ad9-b79f-5e999a9a3e86@u72g2000hsf.googlegroups.com>, tadamsmar writes:
    >On Mar 13, 2:04=A0pm, VAXman- @SendSpamHere.ORG wrote:
    >> In article <1f5f98b1-5433-4687-953d-c3ac4a3e0...@m44g2000hsc.googlegroups.=

    >com>, tadamsmar writes:
    >>
    >> >On Mar 13, 12:07=3DA0pm, VAXman- =A0@SendSpamHere.ORG wrote:
    >> >> In article

    >ps.=3D
    >> >com>, tadamsmar writes:

    >>
    >> >> >{...snip...}

    >>
    >> >> >Opps, not quite there. =3DA0It ran clean on the single disk. =3DA0But =

    >when I
    >> >> >add the other disk to the shadowset it reported the 4 blocks with
    >> >> >errors. =3DA0VMS does not want to give these up without a fight.

    >>
    >> >> >I'm am going to init/erase that disk.

    >>
    >> >> What happens if you shadow and mount an init'd disk (i.e. nothing on it=

    >)?
    >>
    >> Aren't you init'ing and then restoring your backup to it?

    >
    >I did an init/erase, and restored the backup. But for the second
    >disk, I did a init/erase and just put into the shadow set. I tried
    >putting the second disk in the shadowset without an init/erase but it
    >still had the 4 bad blocks, so I did and init/erase on it.
    >
    >I never tried a plain old init.
    >
    >I still don't quite understand what you are asking, or why.


    Just trying to understand where your "bad" blocks come from.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  4. Re: Shadow set problem finally solved

    tadamsmar writes:

    >On Mar 13, 8:33=A0am, tadamsmar wrote:
    >> It worked! =A0I finally got a clean ANAL/DISK/SHADOW!


    >Opps, not quite there. It ran clean on the single disk. But when I
    >add the other disk to the shadowset it reported the 4 blocks with
    >errors. VMS does not want to give these up without a fight.


    Did you get those errors from $ ANAL/DISK/SHADOW or from when the shadow
    copy was taking place? If the latter, those bad blocks may already be
    gone.

    Due to speed/synchronization issues, a shadow copy doesn't blindly copy
    blocks from the source to the target. It reads from the target and
    compares them to the source. If different, the source is copied to the
    target.

    Now, if the target had 4 blocks marked as bad, they would have been
    reported during the read. However, they would have been immediately
    overwritten, and by now would be gone. I forgot about that. If they're
    reported by $ ANAL/DISK/SHADOW, I guess I don't know.

  5. Re: Shadow set problem finally solved

    On Mar 13, 7:04*pm, moro...@world.std.spaamtrap.com (Michael Moroney)
    wrote:
    > tadamsmar writes:
    > >On Mar 13, 8:33=A0am, tadamsmar wrote:
    > >> It worked! =A0I finally got a clean ANAL/DISK/SHADOW!

    > >Opps, not quite there. *It ran clean on the single disk. *But when I
    > >add the other disk to the shadowset it reported the 4 blocks with
    > >errors. *VMS does not want to give these up without a fight.

    >
    > Did you get those errors from $ ANAL/DISK/SHADOW or from when the shadow
    > copy was taking place?


    From the shadow copy.

    > If the latter, those bad blocks may already be
    > gone.
    >
    > Due to speed/synchronization issues, a shadow copy doesn't blindly copy
    > blocks from the source to the target. *It reads from the target and
    > compares them to the source. *If different, the source is copied to the
    > target.
    >
    > Now, if the target had 4 blocks marked as bad, they would have been
    > reported during the read. *However, they would have been immediately
    > overwritten, and by now would be gone.


    I guess you are saying that I got 4 read errors on the reads, but they
    would have been overwritten, so that I would have never seen them
    again.

    Too late to confirm that idea on the disk that I have installed since
    I erased it. But I will probably reinstall the old disks and send the
    new ones back to the vendor. When I put the old disk in, it will be
    carrying 4 "bad" blocks, so I could confirm your idea.

    > I forgot about that. *If they're
    > reported by $ ANAL/DISK/SHADOW, I guess I don't know.

    |

  6. Re: Shadow set problem finally solved

    On Mar 13, 3:20*pm, VAXman- @SendSpamHere.ORG wrote:
    > In article <444fde84-b0dc-4ad9-b79f-5e999a9a3...@u72g2000hsf.googlegroups.com>, tadamsmar writes:
    >
    >
    >
    >
    >
    > >On Mar 13, 2:04=A0pm, VAXman- *@SendSpamHere.ORG wrote:
    > >> In article <1f5f98b1-5433-4687-953d-c3ac4a3e0...@m44g2000hsc.googlegroups.=

    > >com>, tadamsmar writes:

    >
    > >> >On Mar 13, 12:07=3DA0pm, VAXman- =...@SendSpamHere.ORG wrote:
    > >> >> In article
    > >ps.=3D
    > >> >com>, tadamsmar writes:

    >
    > >> >> >{...snip...}

    >
    > >> >> >Opps, not quite there. =3DA0It ran clean on the single disk. =3DA0But =

    > >when I
    > >> >> >add the other disk to the shadowset it reported the 4 blocks with
    > >> >> >errors. =3DA0VMS does not want to give these up without a fight.

    >
    > >> >> >I'm am going to init/erase that disk.

    >
    > >> >> What happens if you shadow and mount an init'd disk (i.e. nothing onit=

    > >)?

    >
    > >> Aren't you init'ing and then restoring your backup to it?

    >
    > >I did an init/erase, and restored the backup. *But for the second
    > >disk, I did a init/erase and just put into the shadow set. * I tried
    > >putting the second disk in the shadowset without an init/erase but it
    > >still had the 4 bad blocks, so I did and init/erase on it.

    >
    > >I never tried a plain old init.

    >
    > >I still don't quite understand what you are asking, or why.

    >
    > Just trying to understand where your "bad" blocks come from. *


    Well, I got some errors logged the very first time I did a shadow copy
    on one of 2 refurb DS10s that I bought last August. I did not have
    time to look into it then and I figured shadowing was protecting me.
    But I got on it recently since I did not want to let my 1 year
    warranty expire before I tackled it.

    I figured I have been copying those errors around ever since.

    I now think there were some bad blocks on one disk. But I will
    probably go back and confirm that. I have the 3 disks I swapped out
    stacked beside me. I am going to swap them all back in and confirm if
    any have some real bad blocks.

    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker * VAXman(at)TMESIS(dot)COM
    >
    > * "Well my son, life is like a beanstalk, isn't it?"
    >
    > http://tmesis.com/drat.html- Hide quoted text -
    >
    > - Show quoted text -



  7. Re: Shadow set problem finally solved

    In article <47d95126$0$5604$607ed4bc@cv.net>, VAXman- @SendSpamHere.ORG writes:
    > In article , tadamsmar writes:
    >>{...snip...}
    >>
    >>Opps, not quite there. It ran clean on the single disk. But when I
    >>add the other disk to the shadowset it reported the 4 blocks with
    >>errors. VMS does not want to give these up without a fight.
    >>
    >>I'm am going to init/erase that disk.


    Actually, there should be no need to.

    The shadow copy actually _reads_ from both disks before overwriting - for
    reasons that are not precisely clear to me - and it is expected behavior
    in that case for a read error to occur given that we already know that
    the target volume has forced error bits. After reading, however, it
    will go forward with overwriting those blocks thus clearing the forced
    error bits.

    I would guess that if you re-ran the shadow copy the errors would have
    disapperared.

    > What happens if you shadow and mount an init'd disk (i.e. nothing on it)?


    VAXman, you may not have been following the entire thread (or set of threads),
    but he has tried a number of things, including

    $ BACKUP/IMAGE source/SAVE_SET original_source_member:

    which of course initializes the volume before writing the files, and has
    not had the problem go away, presumably because nothing has ever written
    to the particular block(s) with the forced error bits.

    The $ INIT/ERASE was an attempt to completely overwrite the volume before
    restoring the backup.

    --
    George Cornelius Remove BEGIN/END delimiters to reply


    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >
    > "Well my son, life is like a beanstalk, isn't it?"
    >
    > http://tmesis.com/drat.html


  8. Re: Shadow set problem finally solved

    On Mar 14, 1:46 pm, BEGINcornel...@decuserve.orgEND (George Cornelius)
    wrote:
    [...]
    > The shadow copy actually _reads_ from both disks before overwriting - for
    > reasons that are not precisely clear to me - and it is expected behavior
    > in that case for a read error to occur given that we already know that
    > the target volume has forced error bits. [...]


    I'm sure there is a post from Keith Parris in the archives about this,
    but
    the initial pair of READs is to save on I/Os if the blocks compare
    equal.
    In the case that they are different, there are 3 additional I/Os
    required,
    IIRC: one to write the data to the target of the shadow copy, another
    to read back the newly written block and make sure its correct, and
    possibly one more to read the source and make sure it hasn't changed?
    See Keith's posts for a more accurate description. ;-}

    -Ken

  9. Re: Shadow set problem finally solved

    Ken.Fairfield@gmail.com writes:

    >On Mar 14, 1:46 pm, BEGINcornel...@decuserve.orgEND (George Cornelius)
    >wrote:
    >[...]
    >> The shadow copy actually _reads_ from both disks before overwriting - for
    >> reasons that are not precisely clear to me - and it is expected behavior
    >> in that case for a read error to occur given that we already know that
    >> the target volume has forced error bits. [...]


    >I'm sure there is a post from Keith Parris in the archives about this,
    >but
    >the initial pair of READs is to save on I/Os if the blocks compare
    >equal.
    >In the case that they are different, there are 3 additional I/Os
    >required,
    >IIRC: one to write the data to the target of the shadow copy, another
    >to read back the newly written block and make sure its correct, and
    >possibly one more to read the source and make sure it hasn't changed?
    >See Keith's posts for a more accurate description. ;-}


    It's actually a clever algorithm that allows the shadow copy to take place
    without having to synchronize access with every file on the shadowset when
    its blocks are copied to the new member. Such synchronization would
    greatly complicate shadowing. Shadowing is complicated enough already.

    I believe Digital had a patent on the algorithm.

  10. Re: Shadow set problem finally solved

    On Mar 14, 8:53*am, tadamsmar wrote:
    > On Mar 13, 7:04*pm, moro...@world.std.spaamtrap.com (Michael Moroney)
    > wrote:
    >
    > >tadamsmar writes:
    > > >On Mar 13, 8:33=A0am,tadamsmar wrote:
    > > >> It worked! =A0I finally got a clean ANAL/DISK/SHADOW!
    > > >Opps, not quite there. *It ran clean on the single disk. *But when I
    > > >add the other disk to the shadowset it reported the 4 blocks with
    > > >errors. *VMS does not want to give these up without a fight.

    >
    > > Did you get those errors from $ ANAL/DISK/SHADOWor from when theshadow
    > > copy was taking place?

    >
    > From theshadowcopy.
    >
    > > If the latter, those bad blocks may already be
    > > gone.

    >
    > > Due to speed/synchronization issues, ashadowcopy doesn't blindly copy
    > > blocks from the source to the target. *It reads from the target and
    > > compares them to the source. *If different, the source is copied to the
    > > target.

    >
    > > Now, if the target had 4 blocks marked as bad, they would have been
    > > reported during the read. *However, they would have been immediately
    > > overwritten, and by now would be gone.

    >
    > I guess you are saying that I got 4 read errors on the reads, but they
    > would have been overwritten, so that I would have never seen them
    > again.
    >
    > Too late to confirm that idea on the disk that I have installed since
    > I erased it. *But I will probably reinstall the old disks and send the
    > new ones back to the vendor. *When *I put the old disk in, it will be
    > carrying 4 "bad" blocks, so I could confirm your idea.


    This did confirm for one of the disks that I suspected was good. You
    log errors during the merge, but never again. ANAL/DISK/SHAD runs
    clean.

    On a disk that I suspected of having some bad blocks (the one that
    probably started this whole problem), I still get a parity errors on
    the ANAL/DISK/SHAD.

    This seems to be an ironic situation. If I were not shadowing, I
    could run the bad block utility on this disk and then use it without
    problems.
    But in a shadow set, it will always a parity error for ANA/DISK/SHAD.
    I could use it, but with spurious errors being reported for every full
    merge and spurious failure on every run of ANAL/DISK/SHAD.

    I have a good disk to replace this bad one, but I wonder if there is
    some way around this, so I could use this disk without all the
    spurious error reports. I might want to keep the disk, it just has a
    few bad blocks.

    >
    > > I forgot about that. *If they're
    > > reported by $ ANAL/DISK/SHADOW, I guess I don't know.

    >
    > |



  11. Re: Shadow set problem finally solved

    George Cornelius wrote:
    > If that is the case, the solution is to overwrite the block in question.


    This was exactly the right answer.

    But folks were making the OP work far too hard in the solutions proposed
    here.

    You can overwrite unallocated blocks on the disk (including the ones
    with forced-error flags set on them) by simply writing a temporary file
    that takes up all the remaining space on the disk. For example:

    $ COPY/ALLOC={#-of-free-blocks-on-disk} _NLA0: disk:[000000]TEMP.FILE
    $ DELETE disk:[000000]TEMP.FILE;

  12. Re: Shadow set problem finally solved

    Ken.Fairfield@gmail.com wrote:
    > the initial pair of READs is to save on I/Os if the blocks compare
    > equal.
    > In the case that they are different, there are 3 additional I/Os
    > required,
    > IIRC: one to write the data to the target of the shadow copy, another
    > to read back the newly written block and make sure its correct, and
    > possibly one more to read the source and make sure it hasn't changed?
    > See Keith's posts for a more accurate description. ;-}


    Close. After writing the target data, we will re-read the source data
    again and then compare it with the target data. Details of the
    algorithms Shadowing uses for Copy and Merge operations are in the
    presentation "OpenVMS Volume Shadowing Merge & Copy Performance" at
    http://www2.openvms.org/kparris/s2003_volshad_perf.ppt

  13. Re: Shadow set problem finally solved

    Keith Parris wrote:
    > You can overwrite unallocated blocks on the disk (including the ones
    > with forced-error flags set on them) by simply writing a temporary file
    > that takes up all the remaining space on the disk. For example:
    >
    > $ COPY/ALLOC={#-of-free-blocks-on-disk} _NLA0: disk:[000000]TEMP.FILE
    > $ DELETE disk:[000000]TEMP.FILE;


    A friend kindly points out that my suggestion actually only overwrites
    the data if high-water marking is enabled for the disk, or if high-water
    marking is disabled, only if you you do:
    $ SET FILE/END disk:[000000]TEMP.FILE
    $ DELETE disk:[000000]TEMP.FILE;
    $ DELETE/ERASE disk:[000000]TEMP.FILE;
    instead of just the DELETE.

    Without high-water marking, the COPY/ALLOC only allocates an empty file
    of the specified size; it does not write data to the blocks.