Contiguous space in a disk on VMS

[Sk Noorul Hassan]

Hi all,

What are the ways to know the available contiguous space in a disk on VMS ?

[John Abbott_2]

There are lots of possible reponses to this, but I guess an easy reply is to consider using a good tool from the VMS freeware collection, like this:

http://h71000.www7.hp.com/freeware/freeware70/dfu/

[Marc Van den Broeck]

Hi,

Use DEFRAG SHOW disc_name/VOL

Rgds
Marc

[John Abbott_2]

For the freeware DFU too use

$ MCR DFU
DFU> report device
.
.
output here that gives lots of juicy info, look under the Free space stats for what you're after.
.
DFU> ^Z

[Wim Van den Wyngaert]

Without tools : make an fdl that created a file of size x with option contiguous.
If create/fdl fails then the space isn't available. Don't forget to delete the file afterwards.

Wim

[Hein van den Heuvel]

DFU is the preferred tool. Eveery system manager should know to use it.


Anyway, even with the tools, when running in a cluster you may want to instruct the system to allocate a large contiguous chunk before reporting. Why? Well each cluster node can (will) have a freeblock cache on the volume which may fragment the freespace for 'others'.
My favourite command for this: $COP/CONT/ALL=999999999 NL: tmp.tmp


Please help us understand why you think you need to know the largests contiguous chunk. Very few software cares about this anymore. Directories need to be contiguous. And I believe there is one database out there, not oracle, that requires it.

hth,
Hein.

[Sk Noorul Hassan]

I have no DFU loaded in the system. so, I have to go as suggested by WIM, or is there any other way ?

[Wim Van den Wyngaert]

The solution of Hein does the same.

You could write a procedure :

$ set noon
$cnt=1000000 ! or whatever
$b:
$ def/us sys$output nl:
$ def/us sys$error nl:
$ copy/cont/alloc='cnt' nl: xxx.lis
$ if $status
$ then
$ write sys$output "''cnt'"
$ del xxx.lis.*
$ else
$ cnt=cnt - 10000 ! or whatever
$ goto b
$ endif

[Hein van den Heuvel]

I suppose you could 'binary search' for the moment where a large contiguous file create starts to work. Not too hard, notably not with my $COPY techinque as you do not need a temp FDL file for that. Start with 2,000,000 blocks (less than 1TB), divide your way down and back up again.

And you could read [000000]bitmap.sys and count bits.

But WHY do you need to know? If it is for a file create, then just try that size.

If it is for a report, then for starters it is a pretty lame/ useless number and it may be good enough to report "Largest contig free space over 500MB", or over 100MB or whatever.

If it is for a serious report, then just knowing the largest chunk is probably not good enough anyway.

You could see whether the more official tool DFO provided teh data needed. It's reporting functions are free.

But anyway, you HAVE to get DFU on the box.

No self respecting OpenVMS syystem manager can live without. It's free, it's good, it's been around, it's highly available, and it has been written/maintained by a Dutch guy... it doesn't get any better!

Cheers,
Hein.

[Wim Van den Wyngaert]

But DFU is not standard. I want to challenge a newbe in this company to get a version downloaded from the internet on the VMS node. Security doesn't allow it.

IMHO : HP should have made the info available thru lexicals long time ago.


Wim

[Ian Miller.]

DFU was written by the Wizard of ODS2 and should be included with VMS. Certainly it should be installed on any VMS systems you have.

As to the original question - what are you trying to do? I wonder if you need to know this.

[Sk Noorul Hassan]

During my application startup after VMS boot, the start up getting terminated with an error "insufficient space, disk full' while trying to create section files on the system. My disk size is 2GB and free space available is almost 1.8 GB

[Hein van den Heuvel]

Hmmm... what is the EXACT message. I don't recognize yours directly:

FUL, device full (insufficient space for allocation)
VOLUME_FULL, volume is full (insufficient space for the request)
DEVICEFULL, device full; allocation failure
:

And how big are those section files going expected to be?

2GB drives (RZ26?) are not too big compared to physical memory and virtual memory these data.
You know that when you initialize a disk, the defautl place for INDEXF.SYS is in the middle right? So max contig would be 1GB, unless one uses INIT/INDEX=...

Are you sure it is a problem with the data disk? Could it be the audit system running out of system disk of something like that?

Hein.

[Ian Miller.]

have you used one of the methods described to determine the largest contiguous free space?

[Ian Miller.]

Do you know why the application wishes to create a contiguous file?

[John Abbott_2]

Sounds more like you should just backup and restore (ie. defrag the volume).. assuming you have the hardware and time.

Also, as per Marc's suggestion with DFO, I thought this HP product was free to use in report mode ?

Failing that, try the freebie report image tool from HP...

http://h71000.www7.hp.com/openvms/storage/dfopage.html

Regards
John.

[Sk Noorul Hassan]

The exact error is, device full; allocation failure

Can it be solved by taking Image backup to a different disk and restore it back ?

[Wim Van den Wyngaert]

I would do "anal/disk/rep" for the disk first. Maybe the free space counters are not correct. Maybe you should do a cleanup.

Wim

[Sk Noorul Hassan]

I did clean up and ana/disk/repair for the disk, still the problem exist. I am unable to create a file of space 10000 blocks also.

[Wim Van den Wyngaert]

Then you need to backup and restore, as said.
Or buy defrag.

Wim

[Hein van den Heuvel]

So that we are all clear here now... this is no longer a contiguous space problem, but just a free space problem right?
Help/mess devicefull warns that lack of contig space my be the cause, but simply being out of space is a more likely cause!

DFU is still your best friend, as it is the fastest tool to report all large files which you can then evaluate whether they can be moved or deleted.

Without that, use DIR/SIZE/DATE/SELE=FILE=SIZE=MIN=10000 [*...]


Good luck,
Hein.

[Wim Van den Wyngaert]

Hein,

I don't think so. He has 1.8 GB free on a 2 GB disk. So, it should be largest contig block.

Wim

[Sk Noorul Hassan]

Thanks for your suggestions. It is a contiguous block problem as there is almost 1.8 GB free space out of 2 GB disk.

[Wim Van den Wyngaert]

There must be a (small) file with blocks all over the disk. If you could find that file and delete it your problem could be solved. Or do copy/cont of the file if it is not to big. If the file creation ever worked, the file could be located with dir/sin=.

But I don't see any simple ways to find it without extra tools.

Wim

[John Abbott_2]

On the device in question, are there any files in the [SYSLOST] directory ?

If you pick some large(ish) files that you know have been modified a lot and do a $ DUMP/HEAD/BLOCK=(START:0,END:0) filename. Then you can see how fragmented the file are by looking to see how many "File Headers" it has and how many "Retrieval pointers" are displayed from the dump command.

You could copy these files and delete the originals (i.e. Basically do what DFU does well) provided there not in use.

It would be much easier to simply defrag the whole disk using backup/image.

Don't be shy now... you can post points at anytime :-)

Kind Regards
John.