Rob van der Heij wrote:
>What we came up with is to run a job now and then that files most
>of the unused space with a single big file that is easy to compress
>(e.g. all blanks) and then remove that file again. I was told this
>did help SFS a lot.
I can confirm what Rob is seeing for Linux.
On an RVA x82, I ran the LISTCFG DEV option of the SIBBATCH program (an RVA
utility, run under MVS)
volume 1
- I put a 1 GB file on the volume using reba
ls -l showed a 1 GB file
SIBBATCH showed a 863.9 MB (not very compressible)
- I removed the file and the volume still SIBBATCH showed 863.9
MB used
- I then put 2 files filled with zeros on the volume, using
100% of the volume
- I removed the 2 files and SIBBATCH showed 103.8 MB used
volume 2
- I put a 1 GB file of zeros on the volume and it took 103.1 MB
(highly compressible)
- I removed the file the volume still showed 103.1 MB
So, I can confirm what Scott Ledbetter mentioned in his note:
1 - Compression is happening under Linux
2 - Under Linux, the RVA does not release space when the file is
deleted.
Something has to write compressible data over the
volume to retrieve the space.
3 - to get maximum space return, at least two files filled with
zeros, totalling 2.2 GB or thereabouts need to
be written and removed to compress the volume to some minimum
size.
ex: df (get free blocks in 1K chunks)
dd if=/dev/zero of=f1 bs=1k count=1123008 1/2 of free
blocks
dd if=/dev/zero of=f2 bs=1k count=1123008 1/2 of free
blocks
Regards, Jim
Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs
t/l 543-4021, 408-463-4021, [EMAIL PROTECTED]
*** Grace Happens ***
