[Info-vax] Odd BACKUP error: unsupported file structure !

[John Wallace]

On Nov 10, 9:06 am, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> Alpha VMS 8.3, the source disk is ODS5
>
> backup/image/ignore=interlock disk1: lda2:/init
>
> %BACKUP-E-OPENIN, error opening $11$DQB0:[ALLIN1.LIB_SHARE]BALLCAP.EPS;1
> as input
> -SYSTEM-W-FILESTRUCT, unsupported file structure level
>
> $ dir/full $11$DQB0:[ALLIN1.LIB_SHARE]BALLCAP.EPS;1
>
> Directory $11$DQB0:[ALLIN1.LIB_SHARE]
>
> BALLCAP.EPS;1                 File ID:  (58136,1,0)
> Size:           12/18         Owner:    [ALLIN1]
> Created:    30-MAR-1996 18:20:43.55
> Revised:    30-MAR-1996 21:29:14.43 (6)
> Expires:    10-JUL-2022 00:00:00.00
> Backup:     <No backup recorded>
> Effective:  <None specified>
> Recording:  <None specified>
> Accessed:   <None specified>
> Attributes: <None specified>
> Modified:   <None specified>
> Linkcount:  1
> File organization:  Sequential
> Shelved state:      Online
> Caching attribute:  Writethrough
> File attributes:    Allocation: 18, Extend: 0, Global buffer count: 0
>                     No version limit
> Record format:      Stream_CR, maximum 0 bytes, longest 96 bytes
> Record attributes:  Carriage return carriage control
> RMS attributes:     None
> Journaling enabled: None
> File protection:    System:RWED, Owner:RWED, Group:RE, World:RE
> Access Cntrl List:  None
> Client attributes:  None
>
> Total of 1 file, 12/18 blocks.
>
> The other *.EPS files in that directory are also Stream_CR and didn't
> generate any error. ANA/RMS on the file uncovered no errors.
>
> I do not trust the disk (which is why I am doing an /IMAGE to a
> temporary disk with goal of reinitialzing this disk and repopulating it.
> But if the backup is unreliable, I may have to think twice about it.
>
> INDEXF.SYS had grown to over 170,000 blocks (I had done a backup of a
> mac on it it it created a gazillion files which took forever to delete.
>
> Knowing what causes this error message might help understanding the
> health level of the disk and the trustability of the backup I am making.
>
> BACKUP is being extremely slow and also slows down disk accesses in
> another DCL process  despite CPU being at 0 and the disk IOs being
> generally below 1 operation per second (sometimes peaks to about 25-30
> for a short time)
>
> Also, Backup is only using a working set of about 1200 pages. Isn't
> backup supposed to use over 10k pages to make itself more efficient ? Or
> was that only on VAX ?

Does BACKUP /IMAGE still have built-in intimate knowledge of the on-
disk structures? How current is that knowledge?

It is documented that MOUNT will produce the FILESTRUCT error message
on certain V7 versions of VMS if the index file has been extended
beyond certain limits. It's already mentioned here that INDEXF.SYS has
been unusually large. Obviously we're not looking at V7 here, but has
BACKUP /IMAGE kept up to date with the changes to MOUNT?

The file ID 58136,1,0 indicates, iirc, that this is indexfile slot
number 58136 or thereabouts, which doesn't immediately sound
excessive, but...

Copy the file in question to another file in another directory,
hopefully with a file header much closer to the start of INDEXF.SYS.
Then re-try the backup, and see if the error message recurs either on
the original file or the new copy?

hth
john