Here is the situation.
There is currently no utility that will actually free up unused space in a
Linux file system that resides on an RVA. The physical management of data
in an RVA is done at a track granularity. This is fine for MVS because
physical management of freespace in MVS is done at a track level. In VM and
Linux, freespace is basically managed at a byterange granularity. For CMD
minidisks, there is a utility called SIBRUB that will write compressible
data into free areas of CMS minidisks. There is also a system extension
called SIBVMCUR that will do the same thing whenever a CMS minidisk is
accessed. There is no equivalent for Linux.
DO NOT run the 'RELEASE MINIDISK' command unless you want to wipe out your
data. RELEASE MINIDISK tells the RVA that all tracks allocated to the
minidisk can be blown away. If you are managing things at a full volume
level, this is the RVA freespace management equivalent of deleting a volume
and redefining it.
For Linux, freespace can be recovered by writing NULLS into areas of the
filesystem that are marked as 'free' in whatever filesystem you are using.
This works because all data in an RVA is compressed when it passes over the
channel interface, and writing long strings of binary zeros into the free
areas of the files systems uses much less space in the storage unit. Jim
Sibley of IBM posted a neat shell script to do this. Hopefully he doesn't
mind my posting it again. No warrantee expressed or implied by anyone, but
I have used it and it does work.
#!/bin/bash
# sample script to write zeroes on the end of all
# mounted ext2 volumes then remove file to compress RVA
# volumes. [EMAIL PROTECTED]
#
# No warranty given or implied by the author or IBM.
# Use at your own risk
#
# 1) display the local ext2 files df -l -t ext2
# 2) remove the heading and root | tail +3
# 3) squeeze out unwanted blanks | tr -s ' '
# 4) use gawk to generate a line for each mounted
# file system of the form
#
# dd bs=1k count="$4" if=/dev/zero of="$6"/zeroes;rm "$6"/zeroes"
#
# where $4 is the fourth column (available space)
# $6 is the sixth column (mount point)
#
# | gawk -F ' ' '{print "dd bs=1k count="$4" if=/dev/zero of="$6"/zeroes;rm
"$6"/zeroes"}'
#
# 5) execute the script | /bin/bash
# you could delete this command if you just want to see the script
generated
# or write it to a file write to a file
#
# the actual command is a single line of code!
df -l -t ext2 | tail +3 | tr -s ' ' | gawk -F ' ' '{print "dd bs=1k
count="$4" if=/dev/zero of="$6"/zeroes;rm "$6"/zeroes"}' | /bin/bash
Use of this script does not require IXFP. I kind of doubt IBM will sell you
IXFP for VM at this point, but the equivalent StorageTek product is called
SVAA for VM, and it will work with any Iceberg/RVA/STK SVA storage unit.
(The RVA and associated software was developed by StorageTek, and the
technology still lives on today three generations advanced in the SVA V2X
storage unit.) It would not be a bad idea to get SVAA for VM so that you
can at least manage your CMS minidisks and monitor your NCL (Net Capacity
Load, the "gas gauge" for an RVA).
Scott Ledbetter
StorageTek
-----Original Message-----
From: Ashley Chaloner [mailto:[EMAIL PROTECTED]]
Sent: December 20, 2002 4:11 AM
To: [EMAIL PROTECTED]
Subject: RAMAC Virtual Array Full !!
Our RVA is full and we don't know how to get the usage back down. The IBM
documentation is ... less than helpful.
We've offline'd 6 (out of 256) DASD, which dropped the usage by 0.5%, but
we'd like it to get it little further down than that.
Boths LPARs hung (got hanged?) and refused to re-IPL, with no error
message at all.
We have tried deallocating DASD ('DETach 10E0 SYSTEM') and labelling
them as "FREE", or putting a clean CMS filesystem on, but to no avail. In
fact, everything tried so far makes the usage creep up by 0.02% every hour
or so.
I'm told "IXFP" might be the thing we need, but I'm also told it only
knows about CMS filesystems, so Linux deleted stuff never gets freed up by
the RVA.
Any help much appreciated.
Ashley Chaloner.
and just for the archives, in case anyone searches for this, before the
system hang, we got the "information" message "CACHE MODERATE ALERT",
which in our case meant disk unit full, which then made both LPARs fall
over. And refuse to re-IPL.
