Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

INDEXF file to large and filled the disk

 
mndavies1
Occasional Visitor

INDEXF file to large and filled the disk

Hello

I have a DEC 3100 running VMS 5.5-2h.

I have 4  RZ28-e hard drives in the system  (DKA0, DKA100, DKA400 and DKA300 which DKa300 is the boot disk)  This a software build tool and is needed to build software for a tool that is used in teh Semiconductor industry        At the moment I cannot create any new software because the INDEXF file is to large  Yes, I PURGED the disk DKA0 where the build sodtware is but the BLOCK status shows 52 Free blocks compaared to 2874324 for DKA100 and 3442356 for DKA300.  DKA0 shows 52 blocks left on the disk.  And the INDEXF file takes up most of the disk.   

I tried making a Standalone backup of DKA0 to DKA400 which is an unused disk.  I had read that useing this method that when backing up and then restoring the INDEXF file became smaller.  So I tried it with the tape drive but a TK50 drive will take probably 15 tapes.  I use these commands in Standalone backuo mode:

$BACKUP/IMAGE/VERIFY DKA0: DKA400:TMX.BCK/SAVE_SET/INIT/NOCRC

The problem is that towards the end of the backup, the program asks for a second volume.  How can two disks that are the same type and size need different amounts of space?

Is there another way to reduce the file size of INDEXF?

Am I on the right track at all?

Any help would be appreciated as I have been working on and off on this challenge for 6 months

I am a UNIX person and my skills with VMS have always be a bit shaky 

Regards

Mike

6 REPLIES 6
Steven Schweda
Honored Contributor

Re: INDEXF file to large and filled the disk

> I have a DEC 3100 running VMS 5.5-2h.

   MicroVAX 3100 model <something>?  Nice antique.

> I have 4  RZ28-e hard drives [...]

   I might be looking for some (cheap) 4GB drives.

> [...] And the INDEXF file takes up most of the disk.

   I don't know how that would happen.  But there are many things I
don't understand.

> [...] a TK50 drive will take probably 15 tapes. [...]

   And an amazing amount of time, I'd expect.

> I tried making a Standalone backup of DKA0 to DKA400 which is an
> unused disk. [...]

   Plausible.  But BACKUP can do many different things.

> [...] I had read that useing this method that when backing up and then
> restoring the INDEXF file became smaller. [...]

   Also plausible, but what are you reading?  The problem here might be
that the INDEXF.SYS shrinkage/optimization won't happen until the
restoration, and you don't get that far.

> $BACKUP/IMAGE/VERIFY DKA0: DKA400:TMX.BCK/SAVE_SET/INIT/NOCRC

   I don't think that /[NO]INIT has any effect when the output is a save
set, and I'd bet that, even with /NOCRC, a BACKUP save set will be (at
least a little) bigger than the source material, and you have
practically no margin.

   But my first question would be why make a save set?  Why not a simple
volume-to-volume operation, like, say:

      BACKUP /IMAGE /VERIFY DKA0: DKA400:

(perhaps with a /NOCRC option)?  If that worked, then I'd expect that
you could simply swap the disks, making the old DKA400 the new DKA0.  (I
don't know where the SCSI ID selection is done on these things, so you
might need to fiddle with some jumpers or switches, unless the drive
position/shelf itself determines that.)

> Am I on the right track at all?

   I think so, but it's been so long since I had a disk-space problem,
that I'd need to do some reading before I got certain about the details.

Mark_Corcoran
Frequent Advisor

Re: INDEXF file to large and filled the disk

As Steven has already indicated, creating a backup saveset of your DKA0 on DKA400 will be at least slightly larger than the contents you are backing up (a little overhead in the structure of the saveset).

Your best bet would be to do an /IMAGE backup from DKA0: to DKA400: then attempt to restore it back the other direction.

How simple it is to do the /IMAGE backup depends on:
a) What files (if any) are open on DKA0 ($ SHOW DEVICE DKA0:/FILES and also do $ INSTALL LIST)
b) Whether or not DKA0: and DKA400: have the same cluster size - $ SHOW DEVICE DKA0: /FULL and $ SHOW DEVICE DKA400: /FULL (otherwise, IIRC, the source of the backup (DKA0:) will inherit the cluster size of the target volume (DKA400:) which might pose future problems.
c) Whether or not DKA400: is otherwise empty (anything on the disk you want to keep, you'll need to move).
d) Whether or not DKA0: or DKA400: are mounted all the time (you need to DISMOUNT DKA400:, MOUNT DKA400: /FOREIGN, BACKUP DKA0: /IMAGE /VERIFY DKA400:, DISMOUNT DKA0:, DISMOUNT DKA400:, MOUNT DKA0:/FOREIGN, MOUNT DKA400: /OVER=ID, BACKUP DKA400: /IMAGE /VERIFY DKA0:)

Like Steven, I'm also a little surprised that your INDEXF.SYS could end up growing to fill most of the disk - meaning no disrespect, are you absolutely sure that this is the case?

$ SHOW DEVICE DKA0: /FULL !This will report the total # of blocks & free # blocks
$ DIR DKA0:[000000]INDEXF.SYS /SIZE=ALL !This will report EOF block/Allocated blocks

For INDEXF.SYS to have consumed most of the disk space, I would expect that you have either had a lot of small files at one time (and possibly also a small cluster size (which will be reported by the SHOW DEVICE DKA0: /FULL), or you are using significant amounts of Access Control Entries in Access Control Lists applied to the files on the disk.

Regarding the two disks of the same type and size needing different amounts of space...

Well, you're attempting to add a backup of what is on DKA0: onto DKA400: in addition to whatever files and directory structures already exist on DKA400: - even just having the top-level/root directory, INDEXF.SYS and BITMAP.SYS on DKA400: is going to consume some space after all.

It may be worth checking a couple of other things...

Are there any logical disk errors which might be responsible for consuming space that would otherwise be available?
$ ANALYZE /DISK /NOREPAIR DKA0:

Sometimes, the amount of free blocks reported by SHOW DEVICE can get out of step with block allocations in BITMAP.SYS
$ SET VOLUME DKA0: /REBUILD=FORCE !To correct

 

There may be typos in the above, due to the time of night and the fact I should be asleep before my alarm goes off in 4.5 hours to get to the airport...

Mark

p.s. I'm guessing that your employer doesn't have an OpenVMS specialist, and you're having to wear multiple hats for multiple jobs?  If it's a critical system, they probably need to revise how it is supported, but I'm sure I'm already preaching to the converted ;-)

[Formerly appearing as woeisme]
Steven Schweda
Honored Contributor

Re: INDEXF file to large and filled the disk

> Your best bet would be to do an /IMAGE backup from DKA0: to DKA400:
> then attempt to restore it back the other direction.

   Define "best".  Doing that would ensure that the original DKA0 will
be overwritten.  I'd try the non-save-set method before I did anything
which might damage the original DKA0.  It's still an image backup.  Call
me risk-averse.

> How simple it is to do the /IMAGE backup depends on:
> a) What files (if any) are open on DKA0 ($ SHOW DEVICE DKA0:/FILES and
> also do $ INSTALL LIST)

   He did say "Standalone backup".  (Which should solve the MOUNT
questions, too, but not the cluster-size questions, although, I might
wonder how likely any non-default parameters are in such a situation.)
By the way, I hope that you're booting that from a disk, not from a
TK50.  Life is too short.

> $ ANALYZE /DISK /NOREPAIR DKA0:

   I like that idea.  Again, I'd want to have a trustworthy backup of
some kind before I repeated that with /REPAIR.

Mark_Corcoran
Frequent Advisor

Re: INDEXF file to large and filled the disk

> I'd try the non-save-set method before I did anything which might damage the original DKA0.  It's still an image backup

Must be the time of night, but I'm not sure I understand.  You also suggest an image backup, but one which does not damage the original DKA0.  Do you mean simply doing the image backup from DKA0 to DKA400 but not then restoringit back to DKA0, just to see how much INDEXF.SYS is shrunk?

 

>He did say "Standalone backup".  (Which should solve the MOUNT questions, too, but not the cluster-size questions,

Ah yes, that didn't stick in my mind during my original reply.

 

>although, I might wonder how likely any non-default parameters are in such a situation.)

Recently bit me on the behind when we decided to defrag a disk by doing exactly this.  Out the window went the specifically-crafted calculations for large index files partly based on cluster size, when the disk being used as a temporary storage medium to backup to and from had a cluster size of 9 vs the 8 that the original disk had;  the original disk then became 9 too.


>By the way, I hope that you're booting that from a disk, not from a TK50.  Life is too short.

Gag.  Last time I used a TK50 was on a MicroVAX 2000.  Slow, slow slow.

 

>Again, I'd want to have a trustworthy backup of some kind before I repeated that with /REPAIR

Absolutely, hence why I suggested /NOREPAIR. It's a trusthardy fool who'd do a /REPAIR after having been advised of errors with /NOREPAIR without doing a backup first.

 

Although the OP clearly indicated that the problem was disk space, two other things spring to mind...

Normally file creation issues on volumes going back to V5 tend to be either the maximum number of files on the volume reached (we used to have this problem at my first company, when a disk hosted a Pathworks volume, and PC users are in the habit of not being economical with the number of files they create or every doing any housekeeping), or INDEXF.SYS not being able to be extended any further.

It may be worth checking to see how many files there are on the volume (DIR DKA0:[000000...]/GRAND) compared to the maximum number permitted (SHOW DEVICE DKA0:/FULL), and how fragmented INDEXF.SYS is (DUMP DKA0:[000000]INDEXF.SYS /HEADER /BLOCK=COUNT=0) - Map Area Words in Use hovering around the 153 mark is bad (of course, you can count the actual number of extensions that it reports

 

[Formerly appearing as woeisme]
Highlighted
Steven Schweda
Honored Contributor

Re: INDEXF file to large and filled the disk

> [...] Do you mean simply doing the image backup from DKA0 to DKA400
> but not then restoringit back to DKA0, just to see how much INDEXF.SYS
> is shrunk?

   Sure.  If an image backup will reduce INDEXF.SYS, then I'd expect
that image backup to do the job as well as one dealing with a save set,
only faster, and writing to only one disk.  If it works, then you have a
good disk in one step, just swap it over to DKA0.

> Gag.  Last time I used a TK50 was on a MicroVAX 2000.  Slow, slow
> slow. [...]

   In those days (1985?) it was better than many alternatives, but in
long-lived systems, it caused more pain sooner than many other parts,
especially as disks grew.

mndavies1
Occasional Visitor

Re: INDEXF file to large and filled the disk

Hi All

I received all your correspondence and it has helped me greatly.  Unfortunately two things got in the way.  First, I had a Unix sysadmin job to tackle and took me half of Saturday. The next was one of my old RZ28's shot crapps.  I took it apart and found that the read/write arm had scored the top platter.  Disk is essentially trash.  Unfortunately my spare disks are in Scotland.  Not very close to California.  I have a new one and it is coming soon and I will make another backup.  I want to make two image backups as I have been baddly burned in the past because I took a short cut and didn't perform a backup.  Sound familiar.  As soon as I get the other backup disk I will continue and I of course communicate what works, what sort of works and what doesn't work at all.  

Thanks for all your help and have a nice day

Mdavies